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ABSTRACT 

A  prototype  flight  simulator  for  the  Fiber-Optically  Guided  Missile  (FOG-M) 
is  presented.  This  prototype  demonstrates  the  practicability  and  feasibility  of 
using  low-cost  graphics  hardware  to  produce  acceptable  simulation  of  flight  over 
terrain  generated  from  Defense  Mapping  Agency  (DMA)  digital  elevation  data. 
The  flight  simulator  displays  a  dynamic,  three-dimensional,  out-the-window  view 
of  the  terrain  in  real-time  while  responding  to  operator  control  inputs.  The  total 
system  cost  (software  and  hardware)  of  the  simulator  is  an  order  of  magnitude 
less  than  most  flight  simulation  systems  in  current  use. 
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I.   INTRODUCTION 

Flight  simulation  has  been  an  important  computer  graphics  application, 
embracing  a  range  of  systems  from  a  $32.00  program  for  a  personal  computer 
[Ref.  l]  to  special  purpose  machines  costing  millions  of  dollars  [Ref.  2].  The 
capabilities  of  these  systems  are  spread  across  a  range  nearly  as  wide  as  their 
costs,  with  great  variances  in  speed  (frames  displayed  per  second),  realism, 
flexibility,  and  area  of  flight.  We  present  here  a  system  that  is  relatively 
inexpensive,  yet  still  fast  enough  to  present  a  real-time  three-dimensional  view  of 
digitized  terrain.  We  built  this  system  on  a  commercially  available,  high- 
performance  graphics  workstation,  the  Silicon  Graphics,  Incorporated  IRIS-2400 
Turbo.  The  IRIS  system  was  selected  because  of  its  local  availability  and  its 
performance  capabilities.  The  flight  simulator  presented  here  does  not  use  the 
natural  color  and  shape  of  individual  terrain  elements  (in  order  to  achieve  real- 
time performance),  but  it  is  sufficiently  realistic  to  provide  the  feeling  of  flight 
and  allow  identification  of  the  displayed  terrain  and  targets. 

A.     FOG-M 

1.      Background 

The  project  presented  here  was  built  in  response  to  the  United  States 
Army    Combat    Developments    Experimentation    Center's   need    to   simulate   the 
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operation  of  the  Fiber-Optically  Guided  Missile  (FOG-M)  [Ref.  3],  but  this  missile 

is   also  being  considered  for  use  by   the  United  States  Marine   Corps   [Ref.   4]. 

Simulation  is  necessary  in  order  to  test  and  evaluate  the  tactics,  doctrine  and 

training  requirements  associated  with  the  missile  without  the  expense  and  danger 

of  actual  firings  during  simulated  combat  field  trials.    The  FOG-M  is  a  generic 

family  of  remotely-piloted,  video-guided  munitions,  but  for  the  purpose  of  this 

prototype  simulator,   the   weapons   are   all   logically   equivalent,   and   the  entire 

family  is  referred  to  as  "the  missile."    In  order  to  avoid  security  constraints,  the 

parameters  and  operational  characteristics  used  in  this  work  were  not  taken  from 

exact  FOG-M  specifications.    The  parameters  and  technical  specifications  are  all 

estimates,    based   on   reasonableness   and    consistency   with   general,   unclassified 

descriptions  of  the  FOG-M. 

2.     Description 

The  actual  FOG-M  missile  is  six  inches  in  diameter,  five  and  one-half  feet 

high,  weighs  eighty-three  pounds,  and  costs  about  $20,000  [Ref.  4].    It  has  a  video 

camera  mounted  in  its  nose,  which  transmits  a  black-and-white  picture  back  to 

the  operator's  console  (which  consists  of  a  television  screen,  a  computer,  and  a 

joystick)  over  the  fiber-optic  link.  (The  simulator  display  offers  the  user  the  choice 

of  either  color  or  black-and-white;  color  is  the  default  for  the  simulator  despite  the 

operator  view  of  the  missile  being  black-and-white.  The  color  compensates  for 

some    of    the     loss    in    realism    and    identifiability     inherent    in    a    polygonal 

representation  of  natural  objects).  Before  launch,  in  normal  operation,  the  missile 
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is  given  a  general  direction  to  a  target  and  the  altitude  of  the  highest  point  within 
its  range.  The  simulator  allows  values  in  excess  of  FOG-M  operational 
capabilities  for  speed,  range,  and  altitude  above  ground  level  (AGL),  but  the 
default  values  of  two  hundred  knots,  ten  kilometers,  and  one  thousand  meters  are 
characteristic  of  this  type  of  missile.  As  soon  as  the  missile  is  in  position,  it  begins 
transmitting  video  images.  When  launched,  the  missile  rises  to  approximately 
two  hundred  feet  above  the  highest  terrain  point,  and  then  levels  off  in  horizontal 
flight  in  the  targeted  direction.  The  operator  controls  the  pan  and  tilt  angle  of 
the  camera  with  the  joystick,  and  can  dial  in  changes  to  the  heading  and  altitude 
of  the  missile.  The  operator  also  has  the  capability  to  zoom  the  camera's  field  of 
view  from  eight  degrees  to  fifty-five  degrees,  and  to  designate  ("lock-on"  to)  a 
target  for  automatic  homing  by  the  missile. 

B.    ASPECTS  OF  FLIGHT  SIMULATION 

There  are  many  aspects  to  flight  simulation.  Modern  commercial  simulators 
provide  sophisticated  mock-ups  of  cockpits  and  controls  and  highly  detailed  out 
the  window  views.  By  mounting  the  simulator  on  a  moving  platform,  a  true  sense 
of  the  physical  feelings  of  acceleration  and  roll  can  be  achieved.  These  systems 
also  cost,  millions  of  dollars. 

One  of  the  first  decisions  that  must  be  made  when  designing  a  flight  simulator 
is,  "For  what  purpose  will  the  simulator  be  used?"  The  answer  to  this  question 
drives  most  of  the  design  decisions  that  have  to  be  made.    Since  the  purpose  of 
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this  project  is  to  provide  a  simulation  of  the  FOG-M  missile  as  viewed  from  its 

operator's  console,   it   is  felt   that   the  most  important  items  to  model   are  the 

simulated  video   display  of  the  terrain   and   the   actual  operator  controls.     The 

terrain  should  appear  realistic  enough  that  its  major  features  are  recognizable  to  a 

person    familiar    with    the    area.      The    controls    should    allow    for    the    same 

functionality  as  the  actual  console.    The  simulator  must,  of  course,  also  provide  a 

feeling  that  the  missile  is  in  motion  over  the  terrain.    The  effectiveness  of  the 

feeling  of  motion  provided  by  a  flight  simulator  can  be  largely  measured  by  two 

criteria:  the  realism  of  the  displayed  scene  and  the  update  rate  of  the  display. 

1.     Realism 

Many  factors  contribute  to  the  perceived  realism  of  a  displayed  natural 

scene.    Early  attempts  to  quantitatively  measure  realism  consisted  of  counting  the 

number   of  "edges"   or   lines   that    a   scene   contained.    This   later  gave   way   to 

counting  the  number  of  "faces"  or  polygons  in  a  scene.  Since  each  polygon  was 

colored  in  a  single  shade,  it  was  felt  that  each  polygon  represented  a  single  "bit" 

of  information  in  the  scene.    Therefore,  the  more  polygons  the  scene  contained, 

the  more  "realistic"  it  was  felt  to  be  [Ref.  5:pp.  27-28]. 

The  latest  advances  in  computer  graphics  have  also  made  this  measure  of 

effectiveness   obsolete.     With    the    introduction   of  systems   that    are   able   to    till 

polygons  with  textured  patterns,  a  single  polygon  can  now  contain  thousands  of 

"bits"  of  information.  As  a  result,  a  scene  drawn  with  a  few  textured  polygons 

can  appear  more  realistic  than  one  with  an  order  of  magnitude  more  untextured 
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ones.  Early  textures  consisted  of  superimposing  things  such  as  mathematical 
noise  functions  or  stripes  on  the  polygons.  More  recent  advances  have  allowed  the 
texture  to  be  derived  from  digital  photographs  of  a  similar  scene.  For  example, 
polygons  representing  a  part  of  terrain  covering  by  meadow  could  be  filled  with  a 
digital  texture  derived  from  an  aerial  photograph  of  a  meadow  [Ref.  5:  p.  28]. 

Since  most  currently  available  graphics  workstations  do  not  support  the 
use  of  texture  filled  polygons,  the  use  of  texture  was  deemed  to  be  outside  the 
scope  of  the  current  project.  Rather,  the  project's  work  concentrated  on 
determining  how  realistically  a  scene  could  be  rendered  in  real-time  incorporating 
only  the  use  of  lighting  and  shading  models  along  with  terrain  hidden-surface 
algorithms.  These  topics  are  covered  in  more  detail  in  Chapter  V. 
2.     Frame  Update  Speed 

Another  important  aspect  of  a  flight  simulator's  performance  is  the  speed 
at  which  it  is  capable  of  displaying  successive  frames  in  a  scene.  The  faster  the 
update  rate,  the  more  continuous  the  motion  appears.  As  a  reference,  standard 
motion  picture  film  is  projected  at  a  rate  of  twenty-four  frames  per  second. 
Although  the  IRIS  workstation  is  capable  of  displaying  up  to  sixty  frames  per 
second,  the  amount  of  computation  that  must  be  done  between  successive  frames 
in  the  simulation  has  limited  the  update  rate  to  an  average  of  three  frames  per 
second.  While  this  presents  a  less  than  smooth  motion,  it  is  felt  to  be  adequate 
for  the  purposes  of  the  prototype. 
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C.    ORGANIZATION 

The  above  sections  of  this  chapter  have  provided  background  on  flight 
simulation  in  general,  and  the  missile  whose  flight  is  specifically  being  simulated. 
Chapter  II  provides  an  overview  of  the  hardware  used  in  running  the  simulation. 
The  structure  and  content  of  the  Defense  Mapping  Agency  (DMA)  Digital 
Terrain  Elevation  Data  (DTED)  are  discussed  in  Chapter  III.  Chapter  IV 
discusses  the  motivation  behind  and  creation  of  the  two-dimensional  contour  map 
displays.  Chapter  V  covers  the  storage  and  use  of  the  DMA  DTED  to  produce  a 
lighted  and  shaded  three-dimensional  polygonal  terrain  display.  The  mathematics 
and  process  involved  in  simulating  flight  over  the  terrain  are  detailed  in  Chapter 
VI.  Chapter  VII  discusses  the  creation,  insertion,  animation,  and  designation  of 
targets.  Chapter  VIII  covers  the  creation  and  drawing  of  cultural  features. 
Chapter  IX  contains  a  user's  guide  for  operation  of  the  FOG-M  simulator. 
Chapter  X  concludes  with  a  discussion  of  limitations,  future  extensions  and 
research  topics,  and  summarizes  the  research  conducted.  Narrative  descriptions  of 
the  modules  and  listings  of  the  program  source  code  for  each  of  the  modules  are 
included  as  Appendices  A  and  B  respectively. 
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II.    COMPUTER  SYSTEM 

As  discussed  in  Chapter  I,  flight  simulators  are  nothing  new.  The  significance 
of  this  work  lies  in  the  speed  with  which  it  was  developed,  the  display  rate 
achieved,  and  the  realism  and  fidelity  of  the  display  in  comparison  to  the  cost  of 
the  system  that  supports  it.  This  project  was  technically  feasible  only  because  of 
the  capabilities  and  high  performance  of  the  IRIS  (Integrated  Raster  Imaging 
System)  Turbo  2400  Graphics  Workstation,  manufactured  by  Silicon  Graphics, 
Incorporated.  Others  have  also  used  the  IRIS  as  a  base  on  which  to  build  flight 
simulators  [Ref.  6].  This  low-cost  ($50,000  to  $100,00)  three-dimensional  display 
system  is  summarized  in  Figure  2.1  and  is  discussed  more  fully  below. 

A.    HARDWARE  AND  SYSTEM  OVERVIEW 

The  IRIS  has  a  conventional  Von  Neumann  type  computer  architecture  but 
adds  custom-built  special  purpose  VLSI  circuits  and  a  pipelined  design  to  provide 
the  graphics  functions  that  are  implemented  in  software  on  other  comparably- 
priced  workstations.  Conceptually,  there  three  pipelined  components  in  the  IRIS 
hardware:  the  applications /graphics  processor,  the  Geometry  Pipeline,  and  the 
raster  subsystem  [Ref.  7:p.  l-l].  The  applications/graphics  processor  is  a 
conventional  Motorola  MC68020  processor  running  at  16.7  MHz.  This  processor 
runs  the   applications   program(s)   within  a  UNIX   System  V  operating  system. 
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ETHERNET  to  Vax  and  other  IRIS 


32  bit  16.7  MHz  Motorola  MC68020  CPU 

6  Megabytes  of  CPU  Memory 

32  1024x768  bitplanes  of  Display  Memory 

Hardware  matrix  multiplier  &  floating  point  accelerator 

Hardware  Gouraud  shading,  depth  cueing  &  backface  polygon  removal 

TM 
12  pipelined  custom  VLSI  Geometry  Engines 

16-bit  Z-buffer  for  Hidden  Surface  Elimination 

2  72  Megabyte  Winchester  Disk  Drives 

60  Hz  non-interlaced  19"  RGB  high  resolution  monitor 
83  key  up-down  encoded  keyboard 

3  button  mouse 

32-button  and  8-dial  valuator  boxes 
Unix  System  V 

Ethernet  zo    VAX's 
IRIS  Graphics  Library 

Features  of  the  IRIS  Turbo  2400  Graphics  Workstation 

Figure  2.1 
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Applications  either  issue  graphics  commands  in  immediate  mode,  in  which  case 
they  are  sent  through  the  Geometry  Pipeline  immediately  as  individual  graphics 
primitives,  or  compile  graphics  commands  into  graphical  objects,  in  which  case 
they  are  sent  through  the  Geometry  Pipeline  as  a  single  geometric  entity  when 
explicitly  called  at  some  later  point  in  time. 

The  Geometry  Pipeline  takes  commands  in  terms  of  the  user's  world 
coordinates,  performs  specified  matrix  transformations  on  them  using  the  matrix 
multiplier  and  floating  point  accelerator  built  into  the  hardware,  and  then  clips 
and  scales  the  transformed  coordinates  into  screen  coordinates.  The  raster 
subsystem  takes  the  screen  coordinates  output  by  the  Geometry  Pipeline  and 
updates  the  bitplanes  (display  memory)  to  contain  the  lines,  polygons,  or 
characters  specified  by  the  input  coordinates.  The  raster  subsystem  also  performs 
polygon  fill,  shading,  depth-cueing,  and  hidden  surface  removal.  A  conventional 
video  controller  uses  the  values  in  the  bitplanes  and  the  color  table  to  produce  an 
image  on  the  monitor. 

B.    SOFTWARE 

The  C  programming  language  is  native  to  UNIX  and  is  the  language  used  for 
ail  of  the  IRIS  system  software.  The  IRIS  Graphics  Library,  which  provides  both 
high-  and  low-level  graphics  and  utility  commands,  can  be  called  in  C, 
FORTRAN,  Pascal,  or  LISP.  However,  due  to  the  built-in  bias  of  UNIX  and  the 
IRIS,  plus  the  local  pool  of  knowledge,  the  C  programming  language  was  the 
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pro  forma  choice  for  programming  all  parts  of  the  FOG-M  simulator.  The  IRIS 
User's  Guide  [Ref.  7]  breaks  the  Graphics  Library  commands  into  the  following 
twelve  categories: 

-  Global  State  commands  initialize  the  hardware  and  control  global  variables, 
and  are  used  mostly  in  FOG-M's  init  iris  routine. 

-  Drawing  Primitives  are  used  throughout  FOG-M.  They  create  points,  lines, 
polygons,  circles,  arcs,  and  text  strings. 

-  Coordinate  Transformations  specify  mappings  within  and  between  user- 
defined  world  coordinates  and  screen  coordinates.  These  are  used  to  move 
targets  and  to  simulate  flight. 

-  Drawing  Attribute  commands  specify  textures  and  fonts.  Although  texture 
would  greatly  improve  the  appearance  of  the  terrain,  the  IRIS  provided 
textures  are  applied  in  the  screen  coordinate  system,  so  they  do  not  scale  or 
tilt  to  conform  to  the  terrain,  and  produce  a  very  artificial  result. 

-  Display  Mode  and  Color  commands  determine  how  the  bitplanes  are  used 
and  what  colors  appear  on  the  screen.  These  include  the  commands  that  set 
double-buffering,  establish  writemasks,  and  define  the  color  table. 

-  Input/ Output  commands  initialize  and  read  the  dials  and  mouse. 

-  Object  Creation  and  Editing  commands  allow  manipulation  of  complex 
displays  as  a  single  entity.  They  are  used  in  all  FOG-M  displays. 

-  Picking  and  Selecting  commands  are  not  used  in  FOG-M. 

-  Geometry  Pipeline  Feedback  commands  are  not  used  in  FOG-M. 

-  Curve  and  Surface  commands  draw  complex  curves  and  smooth  surfaces. 
Experiments  with  these  produced  more  realistic  terrain  images,  but  not  even 
close  to  real-time,  making  flight  animation  impossible. 

-  Shading  and  Depth— cueing  commands  provide  Gouraud  shading  of  polygons 
and  intensities  that  vary  with  distance  from  the  viewer. 

-  Textport  commands  define  an  area  of  the  screen  for  text.  They  are  not  used 
in  FOG-M. 

Also  available  on  the  system,  and  used  by  FOG-M,  are  the  math  library  with 

sine,  cosine,  arctangent,  hypotenuse,  and  exponentiation  functions,  and  routines 

that  access  the  system  clock  in  order  to  determine  elapsed  time. 
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III.   DIGITAL  ELEVATION  TERRAIN  DATA 

A.  INTRODUCTION 

Unlike  other  flight  simulation  systems,  which  may  rely  on  manual  creation  of 
the  terrain  [Ref.  8],  the  source  data  for  the  terrain  in  the  FOG-M  simulation  is  a 
Defense  Mapping  Agency  (DMA)  digital  terrain  elevation  database  (DTED)  for 
Fort  Hunter-Liggett.  California.  The  database  is  not  Level  1  DTED.  but  rather  a 
DMA  special  product  produced  about  1980  at  a  higher  resolution  than  normal 
Level  1  DTED  fRef.  9].  Level  1  DMA  data  contains  elevation  points  spaced  at 
three  arc-second  intervals,  or  approximately  every  one  hundred  meters.  The  Fort 
Hunter-Liggett  special  data  contains  points  at  twelve  and  one-half  meter  spacing, 
which  is  eight  times  the  resolution  of  Level  1  data. 

B.  COVERAGE 

The  area  covered  by  the  database  is  thirty-six  kilometers  wide  and  thirty-five 
kilometers  high,  with  6400  data  points  per  square  kilometer.  This  area  includes 
most  of  Fort  Hunter-Liggett  plus  some  surrounding  land,  and  is  bounded  by 
latitudes  36  05'  00"  (to  the  north)  and  35  50'  00"  (south)  and  longitudes 
121  04'  30"  (east)  and  121  20'  30"  (west).  In  terms  of  Universal  Transverse 
Mercator  (UTM)  coordinates,  the  area  has  easting  (X)  of  10SFQ41000  to 
10SFQ77000   and   northing   (Y)   of  10SFQ60000   to   10SFQ95000.   The  database 
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appears  to  be  based  on  DMA  forty  foot  interval  contour  map  products,  because 
peaks  tend  to  have  flattened  tops.  This  was  confirmed  both  by  a  comparison  of 
surveyed  instrumentation  sites  on  or  near  peaks  with  their  digital  terrain  values 
[Ref.  10:  pp.  1-2],  and  by  a  Bezier  surface  patch  image  of  the  data  created  locally. 

C.    STRUCTURE 

The  data  is  stored  in  an  unformatted  sequential  file  that  is  organized  as  a 
stream  of  integers.  Each  integer  (sixteen  bits)  represents  both  the  vegetation  code 
and  bald  terrain  elevation  in  feet  at  one  sampling  point,  as  illustrated  in  Figure 
3.1  below. 


bit: 


Veg.  Code 


15     14     13 


Bald  Terrain  Elevation 


12     11     10     9876543210 


Figure  3.1    DTED  Data  Encoding 


The  thirteen  low-order  (rightmost)  bits  contain  the  elevation,  allowing  a  range 
from  zero  to  8191  feet,  although  the  highest  point  in  the  database  is  3744  feet. 
The  three  high-order  (leftmost)  bits  specify  one  of  eight  vegetation  codes,  which 
are  given  in  Table  3.1  below.  Vegetation  codes  are  only  available  for  points 
within   the   boundaries  of  Fort   Hunter-Liggett   proper.   The  file   is  written  one 
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TABLE  3.1  DTED  VEGETATION  CODES 


Code 

Description 

0 

Less  than  one  meter 

1 

One  to  four  meters 

2 

Four  to  eight  meters 

3 

Eight  to  twelve  meters 

4 

Twelve  to  twenty  meters 

5 

Greater  than  twenty  meters 

6 

No  data  available 

7 

Unused 

square  kilometer  at  a  time,  beginning  with  the  lower  left  one  kilometer  grid  square 
(41,60),  proceeding  up  the  column  to  the  upper  left  grid  square  (41,94),  then 
doing  the  next  column  from  bottom  to  top  (42,60  to  42,94)  and  so  on;  the  upper 
right  one  kilometer  grid  square  (76,94)  is  the  last  one  written.  Within  each  one 
kilometer  grid  square,  the  individual  data  points  are  written  in  the  same  pattern, 
beginning  with  the  lower  left,  doing  each  column  from  bottom  to  top,  and  doing 
the  columns  from  left  to  right.  This  file  layout  is  summarized  in  Figure  3.2.  The 
position  in  the  file  of  the  elevation  for  a  point  expressed  in  five  digit  local  UTM  X 
and  Y  coordinates  is  found  as  shown  in  Equation  3.1. 

position  =  35  *  (integer (X / 1000)  -  41)  +  (integer (Y/ 1000)  -  59)       (3.1) 

D.     LOCATION 

The  complete  DTED  rile  occupies  16,128,000  bytes  of  storage.  Due  to  a  local 
shortage  of  available  disk  space,  this  file  must  permanently  reside  on  the  UNIX 
VAX   11/785  system  rather  than  on  the  IRIS  system.     The  FOG-M  simulator 
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presently  operates  on  a  ten  kilometer  square  extract  from  this  database.  A 
program  on  the  VAX  called  make  — database— e  allows  interactive  specification 
of  the  area  and  resolution  desired,  and  produces  an  extract.  This  extract  is  sent 
over  the  Ethernet  to  the  IRIS  to  serve  as  the  input  for  a  FOG-M  run.  However,  if 
the  data  is  sent  directly,  it  is  received  with  each  pair  of  bytes  swapped,  so  another 
program,  swapdma,  is  run  on  the  VAX  before  transmittal.  This  program  swaps 
the  low-  and  high-order  bytes  of  each  integer  so  that  the  swapping  during 
transmission  is  cancelled. 
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IV.   TWO-DIMENSIONAL  TERRAIN  MAP  PORTRAYAL 

The  two-dimensional  representation  of  the  terrain  was  begun  as  the  first 
graphics  portion  of  the  system,  in  order  to  gain  familiarity  with  the  IRIS  graphics 
workstation  and  the  Defense  Mapping  Agency  (DMA)  digital  terrain  elevation 
data  (DTED).  Contour  maps  are  the  traditional  approach  to  two-dimensional 
terrain  portrayal,  and  thus  were  the  basis  for  the  two-dimensional  images  of  the 
terrain  generated  here  (Figure  4.1).  Although  these  two-dimensional  images  are 
not  true  contour  maps,  they  are  still  referred  to  as  such  in  this  study  because  of 
their  close  relation  and  common  origin.  The  algorithms  for  determining  and 
drawing  the  forty  foot  contour  lines  found  on  a  normal  contour  map  seemed  non- 
trivial,  so  a  simpler  alternative  was  chosen.  Each  elevation  datum  is  represented 
by  a  tile,  with  the  implicit  X  and  Z  (easting  and  northing,  respectively) 
coordinates  of  the  elevation  datum  being  the  center  of  the  tile. 

A.     COLORS 

The  color  of  a  tile  is  determined  by  its  vegetation  code,  and  its  intensity  (or 
shading)  by  its  elevation.  The  intent  was  to  use  green  for  tiles  with  vegetation 
and  brown  for  tiles  without  vegetation.  However,  the  DTED  vegetation  codes 
lump  together  both  "no  vegetation"  and  "vegetation  less  than  one  meter  high." 
Brown  tiles  thus  include  both  unvegetated  areas  (e.g.  rock  slabs,  areas  above  the 
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treeline)    and   grasslands  or  meadows.     This   is   significant   in   the   Fort    Hunter- 

Liggett  area,  because  most  of  the  valleys  are  covered  in  grass,  and  all  of  the  high 

ground  is  below  the  treeline.  The  result  is  a  map  with  brown  valleys  and  green 

ridgelines.     While  this  was  readily  accepted  as  natural  by  most  viewers,  pilots 

with  a  background  in  low-level  flight  found  it  awkward,  and  contrary  to  their 

expectations  (from  flight  charts)  of  green  valleys  and  brown  mountains.    While 

this  might  be  significant  in  other  flight  simulation  applications  (particularly  those 

designed  for  pilots),  the  initial  representation  was  deemed  most  appropriate  for 

the  target  audience  of  the  FOG-M  simulator. 

A  similar  initial,  intuitive  choice  was  made  for  the  elevation-keyed  shading. 

High  intensity  (light)   colors  were  used  for  higher  elevations,  and  low  intensity 

(dark)   colors  for  lower  elevations.   This  was  accepted  as  natural  by  almost  all 

viewers.  The  optimum  number  of  intensities  (shadings)  to  use  in  the  map  was 

experimentally  determined  to  be  sixteen.    A  small  power  of  two  was  desirable  due 

to  the  nature  of  the  writemasks  used  to  improve  display  speed.  A  large  number  of 

colors  provides  greater  elevation  definition  and  prevents  large  masses  of  the  same 

color   in    areas  where   elevations   change   gradually.   However,   having   too   many 

colors  destroys  the  contour-map  effect,  since  adjacent  colors  are  so  close  that  no 

boundary  is  distinguishable  between  them.  Eight  shades  each  of  green  and  brown 

were  used  initially.  The  shift  to  sixteen  shades  of  each  produces  a  better  looking 

map.  Due  to  the  RGB  (red,  green,  blue)  nature  of  color  creation  on  the  IRIS,  the 

greens  were  still  barely  differentiable  at  thirty-two  shades,  but  the  browns  (a 
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combination  of  mostly  red,  some  green,  and,  in  some  shades,  a  trace  of  blue) 
began  to  blend  together. 

To  determine  the  elevations  at  which  color  shades  should  change  (in  order  to 
use  the  full  range  of  shades),  the  maximum  and  minimum  elevations  of  the 
terrain  section  in  use  must  be  known.  Rather  than  preprocess  the  data  before  each 
run,  these  values  are  coded  as  constants  in  a  header  file.  The  equation  for  which 
color  index  to  use  is  straightforward  (see  Equation  4.1)  but  takes  significant  time 
when  repeated  ten  thousand  times. 

elevation—  MIN 
index  =  base   index  +  *  #    of  shades  (4.1) 

MAX-MIN 

Therefore,  the  fifteen  points  at  which  the  shade  changes  are  precalculated  and 
stored  in  an  array  so  that  no  calculations  are  needed  at  each  point,  just  an  array 
lookup. 

B.     DRAWING 

The  map  can  then  be  produced  by  determining  the  color  and  shade  for  each 
tile,  and  drawing  it  as  a  filled  square.  However,  an  increase  in  speed  can  be  gained 
by  exploiting  the  structure  of  the  data  and  the  line  drawing  hardware  of  the  IRIS. 
The  data  is  stiil  processed  a  point  at  a  time  within  each  one  kilometer  column, 
but  no  drawing  is  done  until  an  elevation/shading  breakpoint  is  reached.  Then  a 
single  line  of  one  tile's  width  is  drawn  to  color  all  tiles  since  the  previous  elevation 
breakpoint. 
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C.     WRITEMASKS 

A  more  significant  speed  improvement  (on  the  order  of  fifty  per  cent  more 
frames  per  second)  was  achieved  with  writemasks.  Writemasks  are  a  relatively 
low-level  hardware  feature  that  can  be  used  for  many  purposes.  In  the  FOG-M 
simulator,  they  are  used  to  prevent  the  contour  map  from  being  overwritten. 
This  allows  the  map  to  be  drawn  only  once  into  the  bitplanes,  and  have  it  remain 
on  the  screen  without  being  re-drawn  during  each  frame  update.  In  order  to 
understand  how  writemasks  work,  one  must  understand  the  layout  and  use  of  the 
IRIS's  color  table  and  bitplanes. 

1.  Color  Table 

The  color  table  associates  a  particular  binary  number  with  a  color. 
When  the  display  system  asks  what  color  some  number  is,  the  color  table  replies 
with  the  intensities  for  the  red,  green  and  blue  color  guns  that  will  produce  the 
color  defined  for  the  input  number.  This  input  number  is  referred  to  as  a 
colorindex.  Thus  the  color  displayed  on  the  screen  depends  on  the  colorindex 
associated  with  a  given  pixel,  and  the  color  associated  with  that  colorindex  in  the 
color  table.  Table  4.1  gives  the  color  table  entries  that  are  the  defaults  on  the 
IRIS  workstation. 

2.  Bitplanes 

The  colorindex  that  is  associated  with  each  pixel  is  stored  in  the  display 

memory,  which  is  composed  of  bitplanes.    Each  bitplane  has  one  bit  for  each  pixel 

on  the  display  screen,  so  a  bitplane  is  1024  bits  wide,  768  bits  high  and  one  bit 
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TABLE  4.1  IRIS  DEFAULT  COLORINDEX  DEFINITIONS 


Color 

Colorindex 

Decimal 

Binary 

Black 

Red 

Green 

Yellow 

Blue 

Magenta 

Cyan 

White 

0 
1 
2 
3 
4 
5 
6 
7 

0000000000000000 
0000000000000001 
0000000000000010 
0000000000000011 
0000000000000100 
0000000000000101 
0000000000000110 
0000000000000111 

deep.  When  used  in  double-buffer  mode  (as  in  FOG-M),  the  IRIS  uses  sixteen 
bitplanes  (numbered  0  to  15)  for  each  buffer.  The  frontbuffer  is  the  one  whose 
binary  contents  define  the  image  being  dispiayed.  While  the  frontbuffer  is  being 
displayed,  the  next  image  is  created  by  issuing  drawing  commands  which  affect 
only  the  backbuffer.  Once  a  new  image  is  completed  in  the  backbuffer,  the 
buffers  are  swapped,  so  the  backbuffer  becomes  the  frontbuffer  and  is  displayed. 
The  old  frontbuffer  becomes  the  backbuffer,  and  is  then  available  for  update. 
3.      Writemask  Example 

Consider  the  pixel  at  location  (0,0)  —  the  lower  left  corner  of  the  screen. 
The  colorindex  of  that  pixel  is  determined  by  sixteen  bits:  one  from  the  lower  left 
corner  of  each  bitplane.  The  display  system  reads  rhose  sixteen  bits  as  a  binary 
number  (the  colorindex),  and  uses  the  color  table  to  determine  what  color  to 
make  that  pixel.  For  example,  using  the  default  colors  defined  in  Table  4.1  above, 
that  pixel  will  be  colored  black  if  all  sixteen  bitplanes  have  zeroes  in  their  lower- 
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left  corners,  since  the  value  of  the  sixteen  bit  binary  number  00000000000000002  is 

zero.  If  the  current  color  is  set  to  magenta  (color  five,  whose  binary  value  has  ones 

in  bits  zero  and  two)  and  a  drawing  command  is  issued,  bitplanes  zero  and  two 

are  set  to  one,  and  all  other  bitplanes  are  set  to  zero,  for  every  pixel  covered  by 

the  drawing  command.  These  pixels  will  now  be  displayed  as  magenta,  because 

the  colorindex  constructed  from  the  sixteen  bitplanes  will  be  000000000000010 12 

(510),  and  the  color  table  tells  the  display  system  that  color  510  is  magenta. 

The    previous    example    showed    that    a    drawing    command    works    by 

placing  ones  in  certain  bitplanes,  and  zeroes  in  all  of  the  rest,  with  the  current 

color  specifying  which  bitplanes  get  which.    A  writemask  tells  each  bitplane  to 

either  allow  or  ignore  the  changes  a  drawing  command  says  to  make.  In  normal 

double-buffered  usage,  the  writemask  is  11111111111111112,  meaning  all  sixteen 

bitplanes  should  allow  updates.  Now  suppose  there  is  an  image  on  the  screen 

which  uses  just  the  default  eight  colors.  Bitplanes  three  through  fifteen  are  all 

zeroes,  because  all  of  the  colors  have  colorindices  with  three  or  less  binary  digits, 

which  will  be  in  bitplanes  zero,  one,  and  two.  If  the  writemask  is  changed  to 

111111111111 10002    after    drawing   the    image,    those   lower   three   bitplanes   are 

"frozen"  and  will  not  be  changed  by  any  drawing  command.  Setting  the  color  to 

black  and  clearing  the  screen  will  not  change  anything.    The  upper  bitplanes  will 

be  set  to  all  zeroes,  which  they  already  were.    The  lower  three  bitplanes  will  be 

told   to   reset   to   zero,   but   will   not    do   it   because  they   are  protected  by  the 

writemask. 
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Now  suppose  you  want  to  draw  a  grey  line  on  top  of  the  image.    The  line 

only  needs  one  color,  so  it  can  be  drawn  in  one  bitplane.  (Two  bitplanes  will  allow 

three  more  colors  on  top  of  the  map,  three  bitplanes  allow  seven,  etc.)    The  first 

"free"  bitplane  is  number  three.  Turning  on  a  bit  in  this  plane  (and  not  turning 

on  any  bits  in  higher  planes)  requires  a  colorindex  in  the  range  10002  to  11112  (810 

to  1510).  Defining  color  eight  in  the  color  table  as  grey,  making  color  eight  the 

current  color,  and  then  drawing  the  line  is  sufficient  to  get  the  image  into  the 

bitplanes,    but    the    display    will    not    show    the    desired    effect.    If    the    image 

underneath  the  line  is  black  (i.e.  bitplanes  zero  through  two  are  all  zeroes  form 

some  pixels),  the  line  will  appear  grey,  as  intended,  for  those  pixels.  However,  if 

the  image  underneath  the  line  is  red  (i.e.  the  lower  bitplanes  contain  0012),  the 

composite  colorindex  retrieved  by  the  display  system  is  0000000000001 00 12  or  910) 

and  since  color  nine  is  not  defined  in  the  color  table,  it  appears  as  black.  Thus 

every  colorindex  that  has  bit  three  (because  the  line  is  in  bitplane  3)  set  to  one 

(i.e.  colorindices  10002  to  111125  or  SlQ  to  1510)  must  be  defined  as  grey  in  order  to 

produce  the  desired  image. 

4.      Writemasks  in  FOG-M 

The    map    image    used   in    FOG-M    is   stored    in    the   first    six  bitplanes 

(numbered    0    through    o)    ot'    both    buffers,    which    means    sixty-four   colors    are 

available:  eight  are  the  IRIS  defaults,  sixteen  are  shades  of  brown,  sixteen  are 

shades    of    green,    and    twenty-four    are    unused.      The    writemask    defined    as 

SAVEMAP  (C016  or  000000001 10000002)  allows  things  to  be  drawn  on  top  of  the 
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map  in  bitplanes  six  and  seven.  Colorindices  64  through  127  are  all  defined  as 
blue  in  the  color  table,  so  anything  drawn  in  bitplane  six  appears  on  top  of  the 
map  in  blue.  Similarly,  bitplane  seven  is  used  for  red,  with  colorindices  128 
through  255  all  correspondingly  defined  to  be  red. 

The  speed  improvement  due  to  writemasks  in  FOG-M  comes  from  not 
having  to  re-draw  the  map  each  time  the  screen  is  updated.  The  cost  is  the  use  of 
many  more  indices  in  the  color  table,  which  limits  the  number  of  colors  available 
for  use  on  top  of  the  map.  For  our  simulation  system,  with  only  two  colors 
needed  on  top  of  the  map,  there  is  plenty  of  room  in  the  color  table.  Therefore, 
the  gain  in  speed  comes  at  no  real  cost. 
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V.   THREE-DIMENSIONAL  TERRAIN  CONSTRUCTION 

A.     REPRESENTATION  DECISIONS 
1.      Polygons  versus  Patches 

Early  experiments  in  the  study  involved  attempting  to  display  the 
terrain  using  parametric  bi- cubic  surface  patches.  A  surface  patch  is  simply  a 
smooth  curved  surface  fitted  to  a  set  of  data  points.  A  discussion  of  the  theory 
and  use  of  surface  patches  can  be  found  in  the  IRIS  User's  Guide  [Ref.  7:sec.  11-3] 
and  Hearn  and  Baker  [Ref.  ll:pp.  193-205].  It  was  quickly  determined  that  it 
would  not  be  possible  to  use  surface  patches  to  represent  the  terrain  and  still 
maintain  a  real-time  update  of  the  terrain  during  flight. 

An  alternate  method  of  displaying  a  three-dimensional  object  is  through 
the  use  of  a  set  of  planar  polygon  surfaces  that  join  at  common  edges  to  form  the 
terrain  object.  This  method  has  the  advantage  of  being  much  simpler,  and 
therefore  faster,  to  generate  and  display.  For  this  reason  it  was  chosen  for  use  in 
the  project. 

Figure  5.1  shows  the  method  of  constructing  the  terrain  surface  as  a  set 
of  triangles.  The  term  gridsquare  is  used  in  the  remainder  of  the  chapter  to  refer 
to  a  set  of  two  triangles  with  a  common  hypotenuse  that  form  a  square  of  the 
terrain  grid. 

34 


A 
"GRID- 
SQUARE" 


North 


t 


East 


View  from  above  looking  down  on  the  terrain 

-Terrain  elevation  points  are  connected 
to  form  triangular  polygons  with  common 
edges . 


Figure  5.1  Polygonal  Terrain  Construction 


35 


2.  Resolution 

The  special  DMA  data  file  used  in  this  project  contains  elevation  data 
that  is  spaced  at  a  twelve  and  one-half  meter  interval.  One  of  the  first  questions 
which  had  to  be  answered  concerning  the  three-dimensional  portrayal  of  this  data 
was,  "In  how  fine  a  resolution  can  the  data  be  displayed,  while  still  allowing  for  a 
sufficient  frame  update  speed?"  Early  test  runs  showed  that  using  the  full  twelve 
and  one-half  meter  resolution  would  be  much  too  slow,  although  it  provided  an 
excellent  representation  of  the  terrain.  An  adequate  frame  update  rate 
(approximately  three  to  four  frames  per  second)  was  achieved  with  a  seventy-five 
meter  resolution  or  every  sixth  data  point.  Since  this  was  an  early  test,  displaying 
terrain  without  any  targets  or  cultural  features,  a  one  hundred  meter  resolution 
was  decided  upon  for  use  in  the  remainder  of  the  project.  This  allowed  for  an 
adequate  "cushion"  of  processing  time  to  complete  the  additional  computations 
that  would  be  needed  in  the  final  product,  while  still  providing  an  adequate 
degree  of  resolution. 

3.  Elevation  Scaling 

After  viewing  the  early  representations  of  the  terrain,  it  appeared  that 

the  hills  did  not  give  an  appropriate  appearance  of  height.    Although  this  was  a 

subjective  judgement,  it  was  shared  by  most  people  who  viewed  the  display  and 

compared  it  to  aerial  photographs  of  the  area.    Because  of  this,  it  was  decided  to 

scale   the   elevations   of  the   displayed   points   upward.     Two   approaches,   linear 

scaling  and  exponential  scaling,  were  examined. 

36 


In  the  linear  scaling  approach,  each  elevation  point  was  simply 
multiplied  by  a  scale  factor  as  shown  in  Equation  5.1. 

Elev        =  a  *  elev  ..  (5.1) 

new  old.  *  ' 

Using  this  approach,  it  appeared  that  a  scaling  factor  between  1.5  and  2.0  was 
necessary  to  achieve  the  desired  effect. 

In  the  exponential  approach,  the  elevation  of  each  point  was  raised  to  a 
fixed  power  as  shown  in  Equation  5.2. 

Elev        =  Elev*  (5.2) 

new  old  v        ; 

This  approach  has  the  effect  of  exaggerating  the  higher  elevations  to  a  greater 
degree  than  the  lower  ones.  It  was  chosen  as  the  approach  for  use  in  the  project 
based  on  subjective  observations  of  the  displays  produced  by  the  two  methods. 
The  scaling  factor,  a,  was  chosen  as  1.05.  Using  this  factor  produces  the 
equivalent  of  a  linear  scaling  of  1.5  for  the  maximum  elevation  and  1.4  for  the 
minimum  elevation  contained  in  our  area  of  interest. 

Subsequent  to  the  decision  to  use  an  exaggerated  elevation  scale, 
research  results  were  discovered  which  supported  it.  In  a  study  conducted  by  the 
U.S.  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences,  observers 
were  asked  to  pick  a  computer  generated  line  drawing  that  best  matched  actual 
terrain.  The  line  drawings  had  different  exaggerations  of  the  vertical  (elevation) 
scale.     The  overall  ratios  chosen  by  the  four  observers  ranged  from   1.25:1   to 
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1.50:1.  The  drawings  presented  to  the  observers  had  exaggeration  ratios  ranging 
from  1:1  to  1.75:1.  [Ref.  12] 

4.      Shading  and  Texturing 

As  explained  above,  each  one  hundred  meter  square  of  the  terrain,  a 
"gridsquare,"  is  represented  by  two  triangles  in  three-space  that  share  a  common 
diagonal  edge.  The  process  of  applying  colors  to  these  polygons,  shading,  was  the 
next  area  of  research  in  the  project. 

a.      Elevation  Based  Shading 

Three  different  shading  algorithms  were  investigated.  The  first  was 
a  simple  algorithm  where  the  shade  of  a  polygon  was  a  function  of  its  elevation. 
Higher  elevations  are  shaded  in  lighter  shades  of  green  while  lower  elevations 
receive  darker  shades.  Equation  5.3  represents  the  assignment  of  a  shade  from  the 
color  map. 

elev  —  Min   Elev 

color  index  =  base   index  +  = *  f    of  shades      (5.3) 

Max  Elev-Min  Elev 

The  darkest  green  is  stored  in  the  base  index  color  map  location  and  the  lightest 
green  in  the  baseindex  +  #  of  shades  location.  Although  this  approach  works 
well  for  two-dimensional  contour  maps  (see  Chapter  IV),  and  is  currently  used  in 
another  "low  cost"'  simulator  [Ret.  6],  it,  did  not  appear  to  present  a  realistic  view 
of  the  terrain.  An  advantage  of  this  approach,  however,  is  that  the  calculation  of 
the  color  index  is  simple  enough  to  be  done  with  no  preprocessing. 
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b.      Lambert's  Cosine  Law  Shading 

The  second  method  of  determining  the  shade  for  a  polygon  involved 

the  use  of  a  point  light  source  and  Lambert's  cosine  law  [Ref.  ll:p.  278].    Let  N 

— > 
be  a  unit  normal  vector  to  the  polygon,  and  I  be  a  unit  vector  in  the  direction  of 

— >  -+  ... 

the  light  source.     The  angle  between   N  and   L,   $,  is  the   angle  of  incidence. 

Lambert's  Law  states  that  the  intensity  of  the  light  reflected  from  the  polygon  is 

proportional  to  cos  $  (Equation  5.4). 

/  a  cos  $  (5.4) 

In  order  to  use  this  law,  the  normal  vector  (iV),  the  light  source  vector  (L),  and 

the  angle  between  them  (<£)  must  be  known.    N  can  be  determined  by  taking  the 

— »  — »  — » 

cross  product  of  vl  and  v2,  where  vl  is  a  unit  vector  in  the  direction  from  vertex 

B  to  vertex  C  of  the  polygon,  and  v2  is  a  unit  vector  in  the  direction  from  vertex 

B  to  vertex  A  of  the  polygon  (Equation  5.5  and  Figure  5.2). 

N  =  vl  x  v2  (5.5) 

With  N  and  L  available,  cos  $  can  be  computed  as  their  dot  product  (Equation 
5.7). 

cos  $  =  .V  •  L  (5.7) 

Since  the  intensity  is  proportional  to  cos  <fr,  the  appropriate  color  index  to  use  can 
be  computed  as 

color  index  =  min  index  +  (#    shades*cos  $)  (5-8) 
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Light  Source 


Figure  5.2  Lambert's  Cosine  Law 
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where     min  index     is     the    color     index    of    the     lowest     intensity     green     and 

min  index  +  #    shades  is  the  color  index  of  the  highest  intensity  green. 

c.      Gouraud  Shading 

The  final  shading  model  investigated  involved  the  use  of  Gouraud 

shading.    The  purpose  of  Gouraud  shading  is  to  provide  a  continuous  transition  of 

shades  across  a  polygon  so  that  the  shades  at  the  edges  of  adjoining  polygons 

match.    This   in   effect   eliminates   the   visible   boundary   between   polygons   and 

provides     a    smooth    continuous    surface.      The     Gouraud     algorithm    involves 

interpolating  to  determine  the  intensity  to  be  used  at  each  pixel  along  a  scan  line, 

and  is  illustrated  in  Figure  5.3  as  reproduced  from  Hearn  and  Baker  [Ref.  ll:p. 

290].    To  use  the  algorithm,  intensity  values  for  each  vertex  of  the  polygon  must 

be  known.     In  the  project's  implementation,  the  intensity  at  each  vertex  was 

computed  as  the  average  of  the  intensity  values  for  all  the  polygons  meeting  at 

that  vertex,  where  the  individual  polygon's  intensity  values  were  calculated  using 

Lambert's  cosine  law. 

The  use  of  this  model  posed  two  problems.    First,  even  though  the 

IRIS  supports  Gouraud  shading  in  its  graphics  library,  its  use  increased  the  time 

between  frames  to  an  unacceptable  rate  (approximately  one  and  one-half  to  three 

seconds   between  frames).     Second,   the  smoothing  of  the  algorithm  worked  too 

well,  resulting  in  terrain  displays  that  lacked  the  necessary  position  cues  to  detect 

motion.    This  second  problem  could  be  alleviated  by  adding  artificial  texture  to 

the  terrain  but  in  light  of  the  speed  problem  it  was  not  pursued  further. 
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Scan  Line 


For  interpolated  shading,  the  intensity  value 
at  point  4  is  determined  from  intensity  values 
at  points  1  and  2,  intensity  at  point  6  is 
determined  from  values  at  points  2  and  3,  and 

intensifies  at  other  points  (such  as  5)  along 
the  scan  line  are  interpolated  between  the 
values  at  points  4  and  6. 


Figure  5.3  The  Gouraud  Shading  Algorithm 
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d.      Adding  Texture 

Lambert's  cosine  law  was  chosen  as  the  shading  model  for  use  in  the 
project,  providing  the  most  realistic  display  within  the  allowed  computation  time 
constraints.  However,  a  problem  with  its  use  is  that  the  flat  valleys,  with  little 
variance  in  the  surface  normals  of  their  polygons,  produce  large  geographic  areas 
having  a  near  constant  shade.  This  results  in  a  lack  of  motion  cues  in  these  areas 
similar  to  that  experienced  with  the  Gouraud  shading  model.  To  remedy  this 
situation,  a  simple  artificial  texture,  in  the  form  of  a  checker  board,  was  imposed 
on  the  terrain.  The  checker  board  effect  was  implemented  as  follows.  First,  the 
shades  for  the  two  triangles  in  each  gridsquare  were  averaged,  and  this  average 
shade  was  used  for  both  of  them.  This  of  course  causes  the  visible  boundary 
between  the  triangles  to  disappear  leaving  a  square  shaded  in  a  single  color. 
Second,  two  slightly  offset  color  ramps  were  used  with  adjacent  grid  squares  using 
different  ramps  to  compute  their  shades.  One  ramp  is  composed  of  green 
intensities  ranging  from  255  to  50,  while  the  other  uses  intensities  ranging  from 
245  to  40.  *  This  causes  the  shades  for  two  adjacent  gridsquares  with  identical 
surface  normals  to  vary,  providing  the  necessary  texturing. 


A  value  of  255  is  the  highest  intensity  green  obtainable,  a  value  of  zero  indicates  the  absence 
of  the  color  green. 
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B.  INTERNAL  DATA  STRUCTURES 

Two  global  arrays  are  maintained  which  store  the  information  necessary  to 
display  the  terrain.  The  first  is  a  five-dimensional  array,  savetriangle ,  that  stores 
the  values  of  the  coordinates  for  each  triangle  making  up  the  terrain  structure. 
The  second  is  a  two-dimensional  array  savecolor  that  stores  the  color  map  indices 
for  each  of  the  terrain's  grid  squares.  The  purpose  and  range  of  each  of 
savetriangle^  indices  is  shown  in  Table  5.1.  For  example, 
savetriangle  [3]  [5]  [l][l]  [2]  would  contain  the  value  of  the  Y  coordinate  (fifth 
dimension  =  2),  of  the  second  vertex  (fourth  dimension  =  1),  of  the  northern 
triangle  (third  dimension  =  1),  of  the  grid  square  with  X  index  five  and  Z  index 
three  (second  dimension  =  five  and  first  dimension  =  three). 

TABLE  5.1  LAYOUT  OF  THE  SAVETRIANGLE  ARRAY 


Dimension 

Index  Range 

Purpose 

Start 

End 

First 

0 

98 

Grid  square  index  in  the  Z  direction.  0 
is  the  southern  most  square,  98  is  the 
northern  most. 

Second 

0 

98 

Grid  square  index  in  the  X  direction.  0 
is  the  western  most,  98  is  the  eastern 
most. 

Third 

0 

1 

Triangle  identifier  within  a  grid  square. 
0  is  the  southern  triangle.  1  is  the 
northern. 

Fourth 

0 

•> 

Vertex  number  of  the  triangle.  0  is  the 
first  vertex,  2  is  the  last. 

Fifth 

0 

2 

Coordinate  identifier  of  the  vertex.  0  is 
the  X  coordinate,  1  the  Y  coordinate 
and  2  the  Z  coordinate. 
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Table  5.2  lists  the  purpose  and  ranges  of  each  of  savecolor's  indices.  For 
example,  savecolor [30]  [10]  contains  the  color  map  index  to  be  used  for  the  grid 
square  with  a  Z  index  of  thirty  and  an  X  index  of  ten. 

TABLE  5.2  LAYOUT  OF  THE  SAVECOLOR  ARRAY 


Dimension 

Index  Range 

Purpose 

Start 

End 

First 

0 

98 

Grid  square  index  in  the  Z  direction.  0 
is  the  southern  most  square,  98  is  the 
northern  most. 

Second 

0 

98 

Grid  square  index  in  the  X  direction.    0 

is  the  western  most,  98  is  the  eastern 
most. 

These  two  arrays  contain  all  the  information  necessary  to  construct  an  image 
of  the  terrain.  The  following  chapter  provides  the  details  of  using  their  data  to 
create  a  real-time,  updated  image  of  the  terrain  as  it  is  seen  from  the  FOG-M's 


camera. 


45 


VI.   FLIGHT  SIMULATION 

A.  OVERVIEW 

The  previous  chapter  discussed  the  methodology  of  constructing  the  three- 
dimensional  terrain  from  the  provided  elevation  data.  This  chapter's  purpose  is 
to  explain  the  details  of  displaying  this  terrain  in  real  time  as  it  is  seen  through 
the  missile's  camera. 

The  high  level  pseudocode  for  the  main  program's  terrain  display  loop  is 
shown  in  Figure  6.1.  Chapter  VII  explains  the  details  of  step  two.  The  details  of 
steps  one  and  six  are  explained  in  Appendix  B  under  the  procedures  readcontrols 
(for  step  one)  and  edit  navbox  and  edit  indbox  (for  step  two).  The  remainder  of 
this  chapter  discusses  the  details,  considerations,  and  results  of  implementing 
steps  three  through  five. 

B.  UPDATING  THE  MISSILE'S  POSITION 

Determining  the  missile's  new  position  can  be  broken  into  two  cases: 

[l]  the  missile  is  under  operator  control  and  its  new  position  is  a  function  of  the 
old  position,  the  commanded  direction  of  flight,  the  commanded  altitude, 
and  the  commanded  speed. 

[2]  the  missile  is  iocked  onto  a  target  and  its  new  position  is  a  function  oi  its  old 
position,  the  position  of  the  desired  target,  and  the  commanded  speed. 

In    both    cases,    a   very    large   simplifying    assumption    is    made    to   ignore    the 

dynamics    of  the    missile's    flight.     This   means   that    the   missile   is   able   to 
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While  missile  is  flying  do 

1)  Read  the  values  from  the  operator's  controls 

2)  Determine  new  positions  for  all  the  targets 

3)  Determine  the  new  position  for  the  missile 

4)  Determine  the  position  of  where  the  camera  is  looking 

5)  Display  the  terrain  as  seen  by  the  camera 

6)  Update  the  operator's  control  indicators 
End  while 

Figure  6.1  Main  Display  Loop  Pseudocode 

instantaneously  change  heading,  speed,  and  altitude.    This  assumption  was  made 
only  because  of  development  time  constraints.    It  is  felt  that  the  computations 
necessary  to  more  realistically   model   the  dynamics  of  the  flight  can  be  done 
without  a  serious  degradation  of  the  simulator's  performance. 
1.      Case  1  -  Operator  Control 

Under  this  case  the  missile's  A",  F,  and  Z  coordinates  are  computed  as 
shown  below. 

ADist  =  Speed*  ATime  (6.1) 
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Where 

-  ADist  is  the  distance  traveled  over  the  ground  since  the  last  position  was 
calculated. 

-  Speed  is  the  missile's  speed  in  feet  per  second  and 

-  ATime  is  the  elapsed  time  since  the  last  position  was  calculated 

Having  calculated   the   distance   the   missile   must   move   during   this  frame,  the 
missile's  new  coordinates  (MX,MY,MZ)  can  be  calculated  as 

MX       =  MX  ,,  +  [cos(Dir      .)  *  ADist]  (6.2) 

new  old      I  V  cmd>  J  V     ") 

MZ       =  MZ  ,,-\sin(Dir      .)* ADist]  (6.3) 

new  old      I         V  cmd'  >  V        I 

MY        =  (Alt      Y  (6.4) 

new         >         cmd'  Vw*^/ 

Where 

-  Dir      .  is  the  commanded  heading  in  radians 

-  Alt      .  is  the  commanded  altitude  in  feet 

cmd 

-  a  is  the  altitude  scaling  factor  (see  Chapter  V,  Section  A. 3). 
2.      Case  2  -  Locked  Onto  a  Target 

In  the  case  where  the  missile  is  locked  onto  a  target,  the  missile's  new 
position  is  computed  as  follows.  ADist  is  computed  as  in  Equation  6.1.  Next  the 
missile's  heading  is  computed  so  as  to  steer  it  directly  toward  the  target's 
position: 

Dir      =  arctan2(-[TZ-MZ\,[TX-MX])  (6.5) 


48 


Where 


-  Dir.  .  is  the  direction  from  the  missile's  position  to  the  target's  position 

-  TX  is  the  X  coordinate  of  the  target's  position 

-  TZ  is  the  Z  coordinate  of  the  target's  position 

-  MX  is  the  X  coordinate  of  the  missile's  position 

-  MZ  is  the  Z  coordinate  of  the  missile's  position 


-  arctan'2(a,b)    is    a    function    which    returns    the    arctan 
0  to  211,  based  on  the  sign  of  a  and  6. 


'   a^ 


{    b  ) 


in    the    range 


Once  Dir.  .  is  known,  the  missile's  new  X  and  Z  coordinates  can  be  calculated  as 

tgt  ' 


MX       =  MX  ,.  +  [cos(Dir,  ,)  *ADist] 

new  old      I  V  tgt '  J 

MZ       =  MZ  ,,-\sin(Dir.  .)  *ADist] 

new  old      l         V  tgt'  ' 


(6.6) 
(6.7) 


Next  the  missile's  altitude  (MY)  is  adjusted  a  proportion  of  the  total  altitude 
difference  between  it  and  the  target,  based  on  the  ratio  of  ADist  to  the  total 
distance  (along  the  horizontal  plane)  to  the  target. 


'tgt 


Disttat  =y/(TX-MX)*  +  {TZ-MZ) 

ADist 


MY      =MY  ,,- 

new  old 


-TY) 


Dist 


tgt  A 


(6.8) 
(6.9) 


Where 


Dint,     is  the  distance  to  the  target  measured  along  a  horizontal  plane. 

MY  and    TY  are  the    Y   (altitude)   coordinates  of  the  missile   and  target, 
respectively. 
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C.     DETERMINING  THE  LINE  OF  SIGHT 

Once  the  new  position  of  the  missile  has  been  calculated,  the  next  step  in 
displaying  the  terrain  is  to  determine  another  point  along  the  camera's  line  of 
sight:  the  look-at  position.  This  calculation  is  also  broken  into  two  cases  based 
on  whether  the  missile  is  or  is  not  locked  onto  a  target  (see  Figure  6.2). 

The  case  where  the  missile  is  locked  on  is  trivial,  the  look-at  position  is 
simply  set  to  the  coordinates  of  the  locked-on  target. 

LX=TX  (6.10) 

LY=TY  (6.11) 

LZ=TZ  (6.12) 

Where  LX,  L  Y,  and  LZ  are  the  X,   F,  and  Z  coordinates  of  the  look-at  position. 
This  centers  the  target  in  the  displayed  three-dimensional  scene. 

When  the  missile  is  not  locked  onto  a  target,  the  camera's  look-at  position  is 
a  function  of  the  missile's  position,  the  missile's  heading,  and  the  pan  and  tilt 
angles  of  the  camera.    It  is  determined  as  follows 

Dirlook  =  Headms[+Pan  (6.13) 

LX  =  MX+[cos(Dirlook)*DistloJ  (6.14) 

LZ  =  MZ-\sin{Dir.     )xDist,    .1  (6.15) 

'-        \         :ook>  look*  \ 

LY  =  MY+[Disthok  *tan(2Y/t)]  (6.16) 
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,  TY,  TZ) 


Case  1  -  Missile  Locked  on  a  Target 


DIR     =  Heading  +  Pan 

look 


(LX,    LY,    LZ), 


Dist 


Loo  Ac" 


>- 


(LX,    LY,    LZ) 


Dist      *    tan (Tilt) 
i-ooAc 


Overhead   View 


Side  View 


Case  2  -  Missile  Not  Locked  on  Target 


Figure  6.2  Determining  the  Camera's  Look-at  Position 
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Where 

-  Dir.    ,  is  the  direction  the  camera  is  looking 

-  Pan  is  the  pan  angle  of  the  camera 

-  Tilt  is  the  tilt  angle  of  the  camera 

-  Dist,  .  is  an  arbitrary  distance  over  the  ground  that  the  camera  looks  ahead. 
Since  the  only  purpose  of  LX,  LY,  and  LZ  is  to  determine  a  point  along  the 
camera's  line  of  sight,  any  positive  number  will  be  acceptable.  A  value  of  five 

kilometers  is  currently  used. 

D.     DISPLAYING  THE  SCENE 

Once  a  line  of  sight  has  been  determined,  the  next  steps  are  to  apply  the 
appropriate  viewing  transformations,  draw  the  filled  polygons  that  make  up  the 
terrain,  and  add  other  items  to  the  scene  such  as  targets  and  roads. 

1.      Viewing  Transformations 

It  is  possible  to  project  a  three-dimensional  object  onto  a  two 
dimensional  viewing  surface  in  two  basic  ways.  In  one  method,  the  parallel 
projection  all  the  points  of  the  object  are  projected  along  parallel  lines.  This  has 
the  advantage  of  preserving  the  relative  dimensions  and  angles  within  an  object 
and  is  used  when  accurate  views  of  various  sides  of  an  object  are  needed  such  as 
in  architectural  drawings.  In  the  other  method,  the  perspective  projection,  all 
the  points  of  an  object  are  projected  along  lines  that  converge  at  a  single  point 
called  the  Center  of  Projection.  In  this  method,  relative  dimensions  are  not 
preserved.  Lines  closer  to  the  projection  plane  appear  larger  than  those  that  are 
more  distant.    The  perspective  projection  provides  a  view  of  three-dimensional 
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objects  that  is  more  realistic,  similar  to  that  provided  by  the  human  eye  or  a 
camera.  Both  these  projections  are  illustrated  in  Figure  6.3.  [Ref.  ll:pp.  235-241] 
Because  of  its  more  realistic  presentation  of  the  scene,  a  perspective 
projection  was  used  for  the  project's  three-dimensional  scenes.  The  IRIS's 
graphics  library  provides  a  procedure  called  perspective  which  constructs  the 
necessary  transformation  matrix*  to  obtain  a  perspective  projection.  The  matrix 
is  defined  as  [Ref.  7:p.  C-2] 


Perspective  (fovy, aspect, near, far) 

fovy 

cot( ) 

2 


aspect 
0 

0 

0 


fovy 

cot( ) 

2 


0 


0 


0 


0 


far + near 

far  — near 

2x/arx  near 

far  — near 


-1 


(6.17) 


Where 


-  fovy  is  the  field  of  view  angle 

-  aspect  is  the  aspect  ratio,  a  ratio  of  the  distance  a  viewer  sees  in  the  X 
direction  to  the  distance  he  sees  in  the  Y  direction.  It  is  generally  set  to  be 
the  same  as  the  ratio  of  the  width  to  the  height  of  the  viewport. 

-  near  and  far  are  the  distances  from  the  viewer  to  the  near  and  far  clipping 
planes. 


A  knowledge  of  using  transformation  matrices  to  perform  graphical  operations  is  assumed 
here.    Hearn  and  Baker  |Ref.  ll:chaps.  11-12]  provides  excellent  coverage  of  the  subject. 
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Proj  ection 


Parallel  Projection 


Perspective  Projection 


Perspective 
Pro j  ection 


Proj  ecti  on 
P  I  ane 


;::::=- 


Center 
of 
Proj  ection 


Closer  lines  appear  larger  than  more  distant 
lines  of  equal  length. 


Figure  6.3  Parallel  and  Perspective  Projections 
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The  perspective  projection  forms  a  view  frustum  as  shown  in  Figure  6.4. 
Any  object  within  the  frustum  between  the  near  and  far  clipping  planes  will  be 
displayed   in   the   scene.     Objects   outside  this  view   volume   are  clipped   and 


discarded. 

Next,  the  frustum  formed  by  the  perspective  projection  must  be 
positioned  along  the  camera's  line  of  sight.  This  is  accomplished  by  another 
transformation  matrix  constructed  via  a  graphics  library  procedure  named  lookat. 
The  lookat  procedure  takes  the  following  inputs: 

-  V  ,    V  ,  and    V  :    the  X,  Y,  and  Z  coordinates  of  the  center  of  projection. 

-  P  ,    P  ,  and    P  :  the  X,  Y,  and  Z  coordinates  of  the  look-at  position. 

-  Twist,  a  right  handed  rotation  of  the  scene  about  the  line  of  sight. 

The  transformation  matrix  formed  by  lookat  is  actually  the  result  of  multiplying 
four  other  transformation  matrices  [Ref.  7:p.  C-2] 


Lookat{Vx  ,Vy  ,Vg  ,Px,Py,Pz,Twist)  = 

Trans{-Vx,-V    -Vz)xRot  (0)x Rot x($)x Rot z(-  Twist) 


(6.18) 


Where  Trans(-V  ,-  V  -V) 


1 

0 

0 

0 

0 

1 

0 

0 

0 

0 

1 

0 

-V      -V 


V     1 


(6.19) 
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Clipping 
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aspect  = 


dy 


The  perspective  command  defines  a  near  and 

far  clipping  plane,  a  field  of  view,  and 
an  aspect,  ratio  . 


Figure  6.4  The  Perspective  Command 
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Roty(Q)  = 


cos(e)  0    -sin{e)  0 

0  10  0 

sin(e)  0     cos(e)  0 

0  0  0  1 


(6.20) 


Rot  (#)  = 


10  0  0 

0     cos($)  sm($)  0 

0    -sm($)  cos(<I>)  0 

0          0  0  1 


(6.21) 


Rot  (-  Twist)  = 


cos(— Twist)  sin{— Twist)  0   0 

—  .sm(—  Twist)  cos{—  Twist)  0    0 

0  0  10 

0  0  0    1 


(6.22) 


And  0  =  sin 


/ 

r.- 

-V 

X 

• 

1  n/CV 

-V) 

'+(**.- 

-vy 

(6.23) 


$  =  sin 


-l 


' 

v  - 

y 

P 

\ 

n/CV 

-vr) 

f(P 

h(pz- 

-y.r) 

(6.24) 


As  can  be  seen,  this  transformation  simply  translates  the  center  of  projection  to 
the  origin,  then  rotates  the  view  frustum  about  X  and  Y  axes  to  align  with  the 
line  of  sight.    Finally  the  twist  angle  is  added  with  a  rotation  about  the  Z  axis. 
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In  the  flight  simulation,  the  twist  angle  is  analogous  to  the  "roll"  angle  of  an 
aircraft  or  missile.    A  value  of  zero  is  currently  used,  but  other  values  could  be 
used  if  the  roll  of  the  missile  during  flight  was  added  to  the  model. 
2.      Determining  Which  Polygons  to  Draw 

After  the  correct  viewing  transformations  have  been  applied,  the 
polygons  that  comprise  the  scene  must  be  drawn.  Although  the  IRIS  will  "clip" 
polygons  which  lie  outside  the  perspective  projection's  view  volume,  an  increase  in 
frame  update  speed  can  be  achieved  by  not  attempting  to  draw  those  that 
obviously  lie  outside.  This  is  discussed  further  in  the  following  section  on 
simulator  performance. 

The  term  view  — bound  is  used  to  describe  a  north-south  oriented 
bounding  box  around  those  parts  of  the  scene  that  are  sent  to  the  graphics 
pipeline.  The  view-bound  is  described  by  the  index  of  the  northernmost, 
southernmost,  easternmost,  and  westernmost  gridsquare  to  be  drawn.  It  is 
calculated  by  extending  (if  necessary)  the  line-of-sight  vector  until  it  intersects  the 
horizontal  plane  Y  =  Min  elev,  where  Min  elev  is  the  minimum  elevation  value 
of  the  terrain.  The  view  — bound  is  calculated  as  being  20  gridsquares  to  the 
north,  south,  east,  and  west  of  this  intersection  point.  If  the  missile's  X  and  Z 
coordinates  are  not  within  the  calculated  view  -bound,  the  bounds  are  extended  to 
include  them.    Figure  6.5  illustrates  this  construction. 
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Missile  Position  (MX,  MY,  MZ) 


Look-at  Position  (LX,  LY,  LZ) 


Horizontal  Plane:  Y  =  Min  elevation 


East  View-bound 


1)  Line  of  sight  vector  is  extended  down 
to  intersect  the  minimum  elevation  plane . 

2)  View  bound  extends  20  gridsquares  north, 
south,  east  and  west,  of  the  intersection. 

3)  Bound  is  extended,  if  necessary  to 
include  the  missile's  position. 


Figure  6.5   Construction  of  the  View-bound 
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3.      Hidden  Surface  Removal 

A  final  detail  that  must  be  taken  care  of  is  the  removal  of  hidden 
surfaces  from  the  scene.  A  hidden  surface  is  simply  a  part  of  the  scene  that  is 
obscured  by  some  object  in  the  foreground,  such  as  a  valley  that  it  hidden  behind 
a  large  hill. 

The  IRIS  supports  a  method  in  hardware  called  Z- Buffering.  In  this 
method,  a  buffer  is  maintained  for  each  pixel  position  on  the  monitor  and 
contains  the  "depth"  (transformed  Z  coordinate)  of  the  part  of  the  scene  that 
generated  that  pixel.  Before  drawing  is  started,  the  buffer  is  initialized  to  the 
maximum  depth  value  (the  value  of  the  far  clipping  plane)  for  each  pixel  position. 
Before  each  new  pixel  is  drawn,  its  depth  is  compared  to  the  depth  stored  in  the 
buffer.  If  its  depth  is  greater  than  the  stored  depth  it  is  not  drawn.  If  it  is  less 
than  the  stored  depth,  it  is  drawn  and  its  depth  value  replaces  the  value  in  the 
buffer.  This  method  could  not  be  used  in  the  project  for  two  reasons.  First,  with 
comparisons  having  to  be  made  on  a  pixel-by-pixel  basis,  it  slows  down  the  frame 
update  rate  to  an  unacceptable  level.  Second,  the  IRIS  does  not  allow  the  use  of 
Z-buffering  and  double-buffering  at  the  same  time.  Double-buffering  is  necessary 
to  implement  the  animation  of  the  scenes. 

Another  common    method   of  hidden   surface    removal    is    che   painter's 

algorithm.     It  derives  its  name  from  the  way  a  painter  would  draw  a  scene  on 

canvas,  drawing  in  all  the  background  and  then  adding  foreground  objects  by 

painting  over  the  background  objects  they  obscure.    Implementing  this  algorithm 
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in  computer  graphics  means  drawing  the  scene  in  an  ordered  fashion,  such  that 
the  most  distant  objects  from  the  viewer  are  drawn  first  and  those  closest  to  the 
viewer  are  drawn  last.  Since  the  gridsquares  comprising  the  terrain  form  well 
denned  rows  and  columns,  an  efficient  implementation  of  this  algorithm  is 
possible.    That  implementation  is  described  below. 

The  implementation  can  be  thought  of  on  a  conceptual  level  as  follows. 
A  line,  perpendicular  to  the  line-of-sight,  is  constructed  to  serve  as  a  pseudo- 
scanline.  Gridsquares  within  the  view-bound  are  drawn  as  they  are  intersected  by 
this  scanline.  The  scanline  is  first  positioned  along  the  line-of-sight  vector  so  that 
it  intersects  the  far  corner  gridsquare  of  the  view-bound.  After  all  the  gridsquares 
along  the  scanline  have  been  drawn,  it  is  moved  one  gridsquare  closer  to  the  view 
position,  along  the  line-of-sight  vector,  and  the  process  is  repeated.  This 
continues  until  all  the  gridsquares  within  the  view-bound  have  been  drawn. 
Figure  6.6  illustrates  this  process. 

From    Figure    6.6,    notice    that    each    scanline    passes    through    three 

gridsquares    in    a    column,    shifts    over    a    column,    then    passes    through    three 

gridsquares  in  the  next  column.    The  number  of  gridsquares  drawn  in  a  column 

(or  row)   before  advancing  to  the  next  column   (or  row)   can  be  determined  by 

computing    the    tangent    of   the    acanline's    direction.     If   the    magnitude    of   the 

tangent    is    greater    than    1.0,    scanlines    will    run    and    shift    along    columns    of 

gridsquares.     If  it   is   less  than   1.0,  scanlines  will  run  and  shift   along  rows  of 

gridsquares.     The  term  .threshold  is  used  in  the  remainder  of  the  algorithm  to 

61 


First_ 
Scanline 


The  Scanlines 


30 

19 

10 

4 

1 

31 

20 

11 

5 

2 

32 

21 

12 

6 

3 

33 

22 

13 

7 

34 

23 

14 

8 

35 

24 

15 

9 

36 

25 

16 

37 

26 

17 

38 

27 

18 

39 

28 

1 

140 

291 

Drawing  Order  of  the  Gridsquares  From 
the  First  5  Scanlines 


Figure  6.6   The  Scanline  Hidden  Surface  Algorithm 
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describe  the  number  of  gridsquares  drawn  before  a  shift  of  column  (or  row)  takes 
place.    It  is  computed  as 


threshold  = 


nearest    integer\ta.n{Dir        J 

J       l  scan' 


nearest   integer 


[tBulDir       )) 

V  V  scan'' 


-1 


if    tan(D?'r        j 

*  scan' 


1.0 


(6.25) 


if 


tan(Z)zr       ) 

v  scan' 


<1.0 


The  pseudocode  for  implementing  the  algorithm  is  shown  in  Figure  6.7. 
The  case  shown  is  for  a  line-of-sight  direction  that  is  in  the  first  octant  (between 

n 

0  and  —   radians).     The   algorithm  for    the   other  seven   octants   is  similar,   the 
4 

difference  being  the  direction  the  scan  line  advances,  and  the  direction  it  shifts 

when  the  threshold  is  reached.     Table  6.1  summarizes  these  parameters  for  all 

eight  octants. 

TABLE  6.1    VARYING  PARAMETERS  FOR  THE  SCANLINE  ALGORITHM 
BASED  ON  THE  OCTANT  OF  THE  LOOK  DIRECTION 


Octant 

Look  Directions 

Scan  Line  Advances 

When  Threshold  is  Reached 

From 

To 

From 

To 

1 

0 

n/4 

North 

South 

Shift  one  column  East 

2 

n/4 

n/2 

East 

West 

Shift  one  row  North 

3 

n/2 

3n/2 

West 

East 

Shift  one  row  North 

4 

3n/2 

n 

North 

South 

Shift  one  column  West 

5 

n 

5n/4 

South 

North 

Shift  one  column  West 

6      ! 

5H/4         3II/2 

West 

East, 

Shift  one  row  South 

i 

3II/2          7II/4 

Hi  as  t 

West 

Shift  one  row  South 

8 

7n/4 

2n 

South 

North 

Shift  one  column  East 

Notice    the    step    draw    gridsquare[z  index][x  index]    in    the    algorithm. 
Since  a  gridsquare  contains  terrain,  and  can  also  contain  roads  and  targets,  an 
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Calculate  the  threshold  value 

count  <-  0 

start   x   index  <—  west   view   bound 
start   z   index  <—  north_view_bound 

While  start   z_index  >  south  view   bound  do 
z    index  <—  start    z    index 
x  index  <—  start_x_index 

while  (x_index  ^  east_view_bound)  and  (z   index  ^  south_view_bound)  do 

{  traverse  a  scanline  } 

draw  gridsquarejz   index] [x   index] 

z    index  —  z    mdex  -  1    {move  it  one  gridsquare  south} 

count  *-  count  -I-  1 

if  count  =  threshold  then 

x    index  «-  x    index  +  1    {move  it  one  gridsquare  east} 

count  <—  0  {  reset  count} 

endif 

end  while 

{move  on  to  next  scanline:  start  it  one  gridsquare  to  the  west} 
start   x  <—  start_x  -  1 
count  «—  0 

if  (start_x  <  west_view_bound)  then 

start  x  <—  west  view   bound 

start   z  <—  start   z  -  threshold 
endif 

endwhile 


Figure  6.7    Pseudocode  for  the  First  Octant  Scanline  Algorithm 

ordering  of  these  parts  of  the  gridsquare  must  also  take  place.    The  two  triangles 
forming  the  terrain  are  drawn  first,  next  any  roads  are  drawn,  and  finally  any 
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targets  are  drawn.    The  details  of  integrating  the  targets  and  roads  into  the  scene 
are  covered  in  the  following  two  chapters. 

The  resulting  scene  is  shown  in  Figure  6.8,  a  photograph  of  the  IRIS 
monitor  during  the  flight  simulation.  Note  how  the  hidden  surface  removal  allows 
the  foreground  hills  to  naturally  obscure  the  valleys  behind  them.  Also  note  the 
effect  of  the  lighting  model  and  texturing  described  in  Chapter  V. 

E.     SIMULATOR  PERFORMANCE 

Data  collected   while  running  the  simulator  shows  that  the  average  frame 
update  rate  is  approximately  four  frames  per  second.    The  Unix  profile  utility 
was    used    to    determine    which    procedures    accounted    for    the   majority   of  the 
simulator's  time  usage.   Table  6.2  shows  the  results  for  the  top  four  routines. 
TABLE  6.2  FOG-M  ROUTINES  USING  THE  MOST  CPU  TIME 


%  CPU  Time 

Routine  Name 

Purpose 

16.9 

polf 

Iris  graphics  library  filled  polygon  routine. 

13.7 

display  terrain 

Output  3-D  scene  with  hidden  surface  removal. 

8.7 

malloc 

C  language  built  in  routine  for  dynamic 
memory  allocation. 

4.5 

gl  findhash 

Low  level  Iris  graphics  library  routine,  used  for 
the  hash  tables  associated  with  graphical 
objects  (Not  user  accessible). 

The  top  two  entries  in  Table  6.2  are  directly  involved  with  outputting  polygons  to 
build  the  terrain  image.  It  is  therefore  reasonable  to  believe  that  the  frame 
update  rate  depends  heavily  on  the  number  of  polygons  that  are  passed  to  the 
geometry  engines. 
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Figure  6.9  is  a  scatterplot  showing  the  frame  update  speed  achieved  when 
various  numbers  of  polygons  were  attempted  to  be  drawn.  The  data  was 
generated  by  reading  the  system  clock  before  each  frame  update  and  calculating 
the  number  of  polygons  based  on  the  view  — bound  that  was  used  during  that 
frame.  The  graph  clearly  shows  the  effect  the  view-bound  has  on  the  frame 
update  rate.  The  next  two  entries,  malloc  and  gl  findhash,  are  traceable  to  the 
making  and  deleting  of  the  graphical  objects  that  store  the  targets  (this  process  is 
explained  in  Chapter  VII).  As  an  experiment,  the  construction  and  deletion  of 
the  targets'  objects  was  removed  from  the  simulation  and  the  targets  were  simply 
displayed  in  stationary  positions.  The  profile  results  from  the  simulator  run  in 
this  configuration  is  shown  in  Table  6.3.  Figure  6.10  is  another  scatterplot, 
generated  in  the  same  manner  as  Figure  6.9,  except  that  the  simulator  was  run  in 
the  stationary  target  configuration.  Eliminating  the  dynamic  memory 
management  associated  with  the  target's  graphical  objects  increased  the  average 
frame  update  rate  from  2.99  to  3.90  frames  per  second.  Also,  the  maximum  frame 
update  rate  achieved  doubled  from  7.5  to  15.0  frames  per  second.  This  would 
suggest  that  an  area  for  further  research  is  an  improved  algorithm  for  target 
updating  that  does  not  involve  dynamically  allocating  memory. 

The  fact  that  the  frame  update  rate  is  so  heavily  dependent  on  the  number  of 

polygons    passed    to    the    geometry   engine   suggests    that    a   more   sophisticated 

method  of  determining  the  view-bound  may  pay  off  in  increased  performance. 

For  example,  the  present  method  does  not  take  into  account  the  field  of  view 
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angle.  It  should  be  possible  to  bound  the  line-of-sight  intersection  point  with  less 
than  twenty  grid  squares  when  the  field  of  view  angle  is  small.  However,  any  new 
algorithm  developed  can  not  be  so  sophisticated  that  it  negates  the  performance 
increase  by  requiring  intensive  computations. 


TABLE  6.3  FOG-M  ROUTINES  USING  THE  MOST  CPU  TIME 
(WITH  STATIONARY  TARGETS) 


%  CPU  Time 

Routine  Name 

Purpose 

23.9 

polf 

Iris  graphics  library  filled  polygon  routine. 

22.3 

display   terrain 

Output  3-D  scene  with  hidden  surface  removal. 

5.5 

color 

Iris  graphics  library  routine  which  sets  the 
current  drawing  color. 

4.1 

line   intersect2 

Finds  the  intersection  point  of  two  lines.  This 
routine  is  used  exclusively  during  the  road 
building  process  and  therefore  is  not  used  at 
all  in  the  display  loop. 

4.0 

poly 

Iris  graphics  library  unfilled  polygon  routine. 
Used  during  the  display  loop  to  outline  the 
road  segments. 
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VII.  TARGET  INTEGRATION 

A.  GENERAL 

The  primary  targets  of  a  FOG-M  missile  are  tanks,  helicopters,  and 
reinforced  ground  installations.  The  simulator  is  designed  to  handle  many  types 
of  targets,  including  various  tanks  and  helicopters,  but  only  a  single  type  of  tank 
is  currently  implemented.  The  prototype  simulator  provides  an  Ethernet 
networking  capability  to  allow  the  input  of  actual  target  positions  in  real-time. 
This  simulates  the  input  that  would  be  received  by  a  production  simulator  during 
computerized  mock  combat  field  experiments.  In  its  networking  mode,  the 
simulator  receives  target  position  and  orientation  data  from  an  interactive 
program  running  on  a  different  IRIS  workstation.  The  target  program,  still  in 
testing  and  not  detailed  in  this  study,  provides  the  capability  to  dynamically 
insert  and  delete  targets  at  any  location,  and  to  modify  their  speed  and  direction. 
In  the  simulator's  stand-alone  mode,  there  are  ten  tanks  defined  by  default  that 
criss-cross  the  ten  kilometer  square  terrain  area.  These  tank  targets  move  at  a 
constant  speed  of  fifteen  knots  and  reverse  direction  when  they  reach  one  of  "he 
edges  of  the  ten  kiiometer  terrain  square.  No  automated  path  planning  is 
presently   performed   in   either   mode,   so   the   tanks   blithely    traverse   even    the 
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steepest  terrain.  The  default  targets  minimize  this  problem  by  traveling  the  length 
of  the  valleys  for  the  most  part. 

B.     TARGET  CREATION 

Target  creation  is  simplified  through  the  use  of  graphical  objects.  The  actual 
image  of  a  tank  is  denned  initially  by  the  tedious  specification  of  the  three 
coordinates  of  each  vertex  of  each  of  the  polygons  that  comprise  the  tank  (Figure 
7.1).  Using  objects,  this  need  only  be  done  once,  placed  in  an  object,  and  then 
referred  to  by  a  single  name  within  each  target  object.  Thus  each  target  is 
described  by  an  object  (the  tank  object)  within  another  object  (the  target  object). 
In  addition  to  the  tank  object,  the  target  object  also  contains  the  transformation 
commands  that  move  the  tank  from  the  origin  to  its  location  on  the  terrain  (a 
translation) ,  and  face  it  in  the  direction  it  is  moving  (a  rotation). 

1.      The  System  Matrix 

The  rotation  and  translation  commands  work  by  modifying  the  system 
matrix.  The  system  matrix  is  a  global  data  structure  that  is  used  to  transform 
coordinates  from  the  three-dimensional  world  space  into  the  two-dimensional 
screen  space.  Each  transformation  can  be  performed  as  a  series  of  computations 
on  individual  X,  Y ,  and  Z  coordinates,  but  the  Transformations  can  also  be 
accomplished  with  a  single  matrix  multiplication.  The  IRIS  has  a  matrix 
multiplier  built  into  its  hardware,  so  matrix  operations  are  very  efficient.  At  least 
three  transformations  must  be  applied  to  every  endpoint  on  the  tank:  a  coordinate 
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sraling,    a   translation,    and    a   rotation.    Rather   than   do   three   separate   matrix 

multiplications,  the  three  transformation  matrices  can  be  combined,  so  that  all  of 

the   transformations   are   accomplished   in   a  single   matrix  multiplication.     The 

matrices  are  combined  by  applying  each  of  them  to  the  system  matrix.    Each 

point  is  now  completely  transformed  through  a  single  multiplication  with  the 

system  matrix.  When  a  new  transformation  is  needed,  the  system  matrix  must  be 

reset   by   applying   the   inverses  of  the  old   transformations,  or  by  copying  the 

original  contents  back  into  the  system  matrix.    Two  commands  are  provided  with 

the  IRIS  to  support  the  latter  method.    Pushmatrix  takes  a  copy  of  the  system 

matrix's     current     contents     and     saves     it     on     the     system  stack.     After     the 

transformations     have     been     applied,     and     the     drawing     that     used     those 

transformations    has    been    completed,    the    system    matrix    is    reset    by    calling 

popmatrix,   which   retrieves   the   copy   placed   on   the   stack   by   pushmatrix   and 

restores  the  contents  of  the  system  matrix  to  the  previously  saved  values. 

2.      Target  Transformations 

The    tank    is    initially    defined    with    its    center    interior    at    the    origin 

(coordinates  (0,0,0)).  While  it  is  not  important  which  point  on  or  in  the  tank  is 

placed  at  the  origin,  it  is  crucial  that  the  tank  be  defined  somewhere  around  the 

origin  in  order  for  the  rotation  command  to  have  the  desired  effect.    The  original 

direction  of  the  tank  is  significant  only  to  the  extent  that  it  must  be  known  in 

order  to  calculate  the  appropriate  rotation  to  achieve  a  specified  heading.  The 

tank  in  FOG-M  faces  to  the  right   (zero  radians  mathematically,  or  a  compass 
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heading  of  ninety  degrees)  initially.  During  target  creation,  dummy  (zero  valued) 
rotation  and  translation  commands  are  placed  in  the  target  object,  to  be  updated 
for  display  by  a  later  editing  of  the  object.  Since  all  rotation  and  translation 
commands  affect  the  system  matrix  (as  previously  described)  and  are  cumulative, 
each  target  object  must  apply  its  transformations,  be  drawn,  and  then  remove 
those  transformations  so  that  latter  drawing  commands  are  not  distorted.  Within 
each  target  object,  the  contents  of  the  system  matrix  are  saved  with  a  pushmatrix 
call,  the  appropriate  rotation  and  translation  commands  are  applied  to  the  system 
matrix  (in  reverse  order,  due  to  the  nature  of  matrix  multiplication),  the  target  is 
drawn  by  calling  the  tank  object,  and  then  popmatrix  is  called  to  reset  the  system 
matrix. 

C.     ANIMATION 

Animation  of  the  targets  is  accomplished  using  the  objects  and 
transformations  described  above.  The  targets  must  be  moved  slightly  before 
being  redrawn  in  the  next  frame.  This  requires  new  (X,  Y,Z)  coordinates,  from  the 
network  or  from  local  calculations.  Then  a  global  data  structure  is  updated  to 
indicate  when  in  the  display  algorithm  the  target  should  be  drawn,  and  the 
translation  command  in  the  target  object  is  edited  to  provide  the  new  coordinates. 
As  each  frame  is  displayed,  targets  appear  in  slightly  shifted  positions,  and  give 
the  appearance  of  animated  motion. 
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The  calculation  of  new  coordinates  requires  the  maintenance  of  position, 
speed,  and  direction  data  for  each  target.  The  total  distance  traveled  between 
screen  updates  is  the  product  of  the  elapsed  time  (obtained  from  the  IRIS's  real- 
time clock)  and  the  target's  speed,  scaled  so  the  units  match.  In  the  networking 
version  of  the  simulator  this  is  done  remotely;  in  the  stand-alone  version 
everything  must  be  maintained  locally.  The  target's  direction  of  travel  is  stored 
in  radians,  and  is  measured  using  the  standard  mathematical  convention  as 
opposed  to  a  compass  heading  (Figure  7.2).  This  allows  calculation  of  the  the 
appropriate  east/west  (AX)  and  north/south  (AZ)  movement  as  follows: 

AX  -cos  (direction)  *  time  *  speed  *  scale   factor  (^-l) 

AZ  =  —sm(direction)  *  time  *  speed  *  scale  factor  (7-2) 

The  new  target  (X,Z)  position  is  the  sum  of  the  old  position  and  the  offsets 
(AX,AZ)  from  Equations  7.1  and  7.2.  Since  all  of  the  current  targets  are  tanks, 
their  Y  coordinates  (altitude)  should  be  taken  from  the  height  of  the  terrain 
underneath  the  tank.  This  is  obtained  from  the  DTED  interpolation  routine 
gnd   level,  which  is  called  with  the  new  (X,Z)  coordinates  as  input  parameters. 

D.     DISPLAY 

Chapter  Five  explained  the  exploitation  of  the  structure  of  the  data  and  the 
use  of  the  painter's  algorithm  to  solve  the  polygon  ordering  problem  without 
resorting  to  slower  or  more  complicated  schemes  like  Z-buffering  or  Binary  Space 
Partitioning  [Ref.  13].    Targets  cannot  merely  be  drawn  after  the  terrain  because 
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of  the  same  ordering  problem.  Otherwise,  targets  appear  in  front  of  everything, 
and  it  is  impossible  to  simulate  a  target  moving  out  of  sight  into  the  distance  or 
behind  some  terrain  feature.  The  implementation  of  the  target  display  algorithm 
is  greatly  facilitated  by  the  use  of  objects.  Objects  allow  the  grouping  of  drawing 
commands  into  a  subroutine-like  package,  which  can  be  edited  (effectively 
allowing  parameterization)  and  then  displayed  with  a  single  command.  A  two- 
dimensional  array  of  object  "names"  (the  object -name -array)  is  initialized  so 
each  element  of  the  array  represents  the  target  object  to  be  drawn  in  the  one 
hundred  meter  square  of  terrain  with  the  same  indices.  Since  the  C  programming 
language  recognizes  the  value  integer  zero  as  FALSE,  and  anything  else  as  TRUE, 
this  array  does  double  duty  as  an  array  of  booleans  indicating  the  presence  or 
absence  of  a  target  object  in  a  particular  one  hundred  meter  grid  square.  (No 
target  objects  are  given  the  "name"  zero,  which  would  indicate  FALSE.)  A  list  of 
targets  is  used  to  reset  this  array  to  all  zeroes  before  each  screen  update  (i.e.  only 
those  elements  that  contained  targets  need  to  be  zeroed)  so  maintenance  overhead 
of  the  array  is  minimized.  The  new  target  positions  are  received  over  the 
network,  or  are  calculated,  based  on  each  target's  position,  speed,  and  direction, 
plus  the  elapsed  real-time  since  the  last  update.  The  appropriate  object-name- 
array  indices  are  calculated  from  the  new  target  position  and  the  object.-name- 
array  is  updated.  If  this  is  the  first  (or  only)  target  in  the  designated  one  hundred 
meter  grid   square,   the   update   is   accomplished  by   making   a  new   object,   and 

setting  the  object-name-array  element  equal  to  the  new  object's  integer  "name." 
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If  the  array  shows  that  some  other  target  is  already  in  that  particular  piece  of 

terrain  (i.e.  the  object-name-array  element  is  non-zero),  the  current  target  is  just 

added  to  the  object  specified  by  the  "name"  in  the  array.    Once  this  has  been 

done   for   each    target,    this    array    is   available   for    the    display  terrain    module. 

Display  terrain  checks  the  array  as  it  draws  each  square  of  the  terrain  to  see  if 

any  targets  should  be  drawn.    If  so,  it  calls  the  indicated  target  object  just  after  it 

has  drawn  the  one  hundred  meter  grid  square  on  which  the  target (s)  rests.    Note 

that  this  causes  the  target (s)  to  be  drawn  at  the  correct  time  for  the  painter's 

algorithm.  The  correct  place   to  draw  the  target  still  must  be  specified  by  the 

transformation  commands  within  the  target  object. 

In  some  cases  it  is  necessary  to  draw  a  target  more  than  once.  Targets  that 

straddle  a  one  hundred  meter  grid  square  boundary  must  be  drawn  on  top  of  both 

(or  possibly  all  four)  grid  squares  in  order  to  avoid  being  partially  obscured  by 

whichever  grid  square  is  drawn  last.  (The  target  must  be  drawn  immediately  after 

the  grid  square  on  which  it  rests  to  ensure  that  the  target  will  be  obscured  when 

it    should    be,   by   terrain    drawn    in   the   foreground.)    Since   the   calculation   of 

boundary  intersection  involves  several  trigonometric  functions  and  an  allowance 

for  the  distance  between  the  center  of  the  tank  and  its  boundaries  (which  varies 

with  the  direction  of  the  tank),  a  simplifying  algorithm  is  used.  If  the  tank  is  close 

enough  to  a  boundary  that  the  most  distant  part  of  the  tank  might  cross  the 

boundary  (see  tanks  A  and  B  in  Figure  7.3),  the  target  object  is  also  drawn  after 

the  adjoining  grid  square(s). 
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The  one  hundred  meter  grid  square  is  essentially  divided  into  three  areas: 
the  middle,  its  sides,  and  its  corners.  In  the  middle,  the  tank  cannot  overlap  any 
other  grid  square.  On  the  sides,  the  tank  may  overlap  one  adjoining  grid  square, 
and  in  the  corners,  the  tank  may  overlap  three  adjoining  grid  squares.  The 
reference  point  on  the  tank  (the  position  the  X,  Y,  and  Z  coordinates  refer  to)  is 
located  at  the  very  center  of  the  tank.  The  tank  is  thirty  feet  long,  so  the  most 
distant  parts  of  the  tank  are  within  a  fifteen  foot  radius  of  the  tank's  reference 
point.  The  lines  that  mark  the  side  and  corner  areas  are  thus  fifteen  feet  inside  the 
borders  of  the  grid  square.  Once  the  tank's  reference  point  is  within  these  areas, 
it  is  potentially  obscured  by  the  later  drawing  of  the  adjacent  grid  square(s).  It 
might  not  be  obscured  if  it  is  paralleling  a  side,  for  example,  but  the  overhead  of 
drawing  it  twice  (or  even  four  times)  when  it  does  not  need  to  be  is  smaller  than 
the  overhead  of  the  calculations  to  determine  if  the  position  and  direction  of  the 
tank  have  it  actually  crossing  one  or  more  edges. 

The  repeated  drawing  is  accomplished  by  adding  a  "new"  target  to  the  array 
of  target  objects.  The  "new"  target  object  is  drawn  at  the  exact  same  location  in 
the  three-dimensional  terrain,  but  it  is  drawn  after  a  different  one  hundred  meter 
grid  square,  so  it  will  have  different  target  object  array  indices,  and  be  in  a 
separate  target  object,  even  though  the  two  (or  four)  targets  drawn  will  overwrite 
each  other  and  produce  a  single  image. 
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VIII.    CULTURAL  FEATURE  INTEGRATION 

The  addition  of  cultural  features  add  much  to  the  realism  of  the  displayed 
scene.  They  also  provide  valuable  landmarks  from  which  a  person  observing  the 
scene  can  geographically  orient  himself.  This  chapter  covers  the  addition  of  one 
type  of  cultural  feature,  roads,  to  the  FOG-M  simulation.  Roads  were  chosen  as 
the  first  feature  to  add  because  of  the  special  problems  associated  with  their 
implementation,  the  ease  of  extracting  their  locations  from  contour  maps,  and  the 
visual  impact  added  to  all  parts  of  the  scene  due  to  their  wide-ranging  locations. 
Three  areas  will  be  discussed:  (1)  the  format  of  the  external  data  file  that  contains 
the  road's  locations,  (2)  the  process  of  mapping  the  roads  onto  the  existing 
terrain,  and  (3)  the  integration  of  the  roads  into  the  terrain  display  loop. 

A.     EXTERNAL  DATA  FILE  FORMAT 

The  data  being  used  in  the  simulation  was  obtained  by  manually  extracting 
the  roads'  positions  from  a  DMA  Topographic  Center  (DMATC)  contour  map  of 
the  area.  Although  this  data  is  available  in  the  DMA's  Digital  Feature  Analysis 
Data  (DFAD)  file,  the  software  necessary  to  access  it  was  not  available.  The  road 
data  file's  format  is  such  that  the  DFAD  data  can  be  easily  used  when  the  access 
software  is  developed. 
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Figure  8.1  shows  a  segment  of  the  file  containing  data  for  two  roads  along 
with  a  diagram  showing  their  locations  within  the  terrain.  Each  road  entry  is 
composed  of  three  parts.  The  first  part  is  the  width  of  the  road  in  feet.  Next  is 
an  integer  N,  where  TV  is  the  number  of  data  points  used  to  digitize  the  road. 
Third  is  a  set  N  coordinate  pairs,  where  each  pair  represents  the  location  of  a 
digitized  point  along  the  road's  centerline.  The  first  coordinate  of  the  pair  is  the 
east-west  location  of  the  point.  It  is  measured  in  feet  from  the  western  terrain 
boundary.  The  second  coordinate  of  the  pair  is  the  north-south  location  of  the 
point,  measured  in  feet  from  the  southern  terrain  boundary.  All  the  data  is  stored 
as  ASCII  text,  which  facilitates  editing  bf  the  data  using  any  text  editor.  The 
DFAD  data  file  also  contains  road  width  information  (in  meters)  and  stores  roads 
as  a  series  of  digitized  points.  The  major  difference  is  that  DFAD's  points  are 
stored  as  latitudes  and  longitudes,  which  need  to  be  converted  before  they  can  be 
used  in  the  simulation.  [Ref.  9] 

B.  CONSTRUCTION  OF  THE  ROAD  POLYGONS 

Knowing  the  width  and  centerline  locations  for  the  road,  the  next  step  is  to 
construct  the  polygons  which  represent  it.  Although,  this  seems  like  a  simple 
procedure,  it  is  complicated  by  the  fact  that  the  road  must  follow  the  rise  and  fall 
of  the  terrain.  Also,  in  order  for  hidden  surface  elimination  to  occur,  the  road 
must  be  divided  at  the  gridsquare  boundaries  so  that  each  piece  can  be  drawn 
along  with  its  corresponding  gridsquare.    The  result   is  that  the  road  must  be 
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Figure  8.1  External  Data  File  Format 
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broken  into  many  planar  polygons,  where  each  polygon  is  a  portion  of  the  road 
that  overlays  one  of  the  terrain  triangles  within  a  gridsquare.  Figure  8.2 
illustrates  this  division  and  defines  some  of  the  terms  used  in  the  description  that 
follows.  The  high  level  pseudocode  for  processing  the  road  data  and  constructing 
the  planar  polygons  is  shown  in  Figure  8.3.  As  the  pseudocode  shows,  each  road 
is  processed  a  segment  at  a  time.    For  each  segment 

-  The  end  points  of  the  segment's  left  and  right  side  are  calculated.  A  look- 
ahead  to  the  next  road  segment  is  done,  allowing  the  ends  of  adjacent 
segments  to  be  calculated  so  that  they  meet  cleanly. 

-  A  bounding  box,  which  contains  all  the  gridsquares  intersected  by  the 
segment,  is  constructed. 

Next,  for  each  gridsquare  in  the  bounding  box,  the  road  segment  is  divided  into 

the  road-polygons  at  the  gridtriangle  boundaries.    Note  that  all  the  vertices  of  the 

road-polygons  fall  into  one  of  five  types: 

-  The  intersection  of  a  segment's  left  side  with  the  side  of  a  gridtriangle. 

-  The  intersection  of  a  segment's  right  side  with  the  side  of  a  gridtriangle. 

-  A  gridsquare's  cornerpoint  that  is  contained  within  the  road  segment. 

-  An  endpoint  of  the  left  side  of  the  road. 

-  An  endpoint  of  the  right  side  of  the  road. 

The  road  polygon  is  constructed  by  finding  all  the  above  vertices  which  exist,  and 

ordering  them  counterclockwise.    The  counterclockwise  ordering  is  necessary  for 

backface  polygon  removal  to  take  place.    The  intersections  only  derine  the  X  and 

Z    coordinates    or    the    vertices.    The     Y    (elevation)    coordinate    is    found    by 

interpolating    between    the    terrain's    elevation    at    the    three    corners    of    the 

corresponding  gridtriangle. 
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While  more  data  in  the  road  data  file  do 
read  width_of_road 
read  number_of_points 

read  segment's  start  coordinate  pair  (seg  _start) 
read  segment's  end  coordinate  pair  (seg_end) 

for  i  =  3  to  number_of_points  +  1  do 

if  i  ^  number_of_points  then 

read  the  next  segment's  end  coordinate  pair  (next_seg_end) 
else 

next   segendx  <—  seg_end_x 

next   seg_end_z  <—  seg_end_z 
endif 

calculate  the  start  and  end  points  for  the  segment's  left  and  right  side 

(left   start,  left    end,  right^start.  right_end) 

calculate  a  bounding  box  around  the  road  segment 

for  each  gridsquare  within  the  bounding  box  do 

Construct  the  polygon  which  overlays  the  gridsquare's  northern  triangle 
Add  the  polygon  to  the  road  object  associated  with  this  gridsquare 

Construct  the  polygon  which  overlays  the  gridsquare's  southern  triangle 
Add  the  polygon  to  the  road  object  associated  with  this  gridsquare 
right   start  *-  right_end 

endwhile 

Figure  8.3  Pseudocode  for  Constructing  Road  Polygons 


C.  INTERNAL  ROAD-POLYGON  STORAGE 

A  global,  two-dimensional  array  of  graphicalobjects,  named  road,  is  used  to 
store  the  road  polygons.  Each  entry  in  the  array  corresponds  to  the  pieces  of  road 
that  lie  within  a  gridsquare.  An  object  is  created  when  the  first  road-polygon  is 
constructed  for  a  gridsquare,  with  subsequent  road-polygons  being  inserted  into 
the  already  existing  object.    Since  the  roads  are  static  in  nature,  the  use  of  objects 
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does  not  present  the  dynamic  memory  allocation  problems  associated  with  their 
use  in  storing  targets  (see  the  Simulator  Performance  Section  of  Chapter  VI).  As 
each  gridsquare  of  the  terrain  is  drawn,  a  check  is  made  to  see  if  a  road  object 
exists  for  that  square.  If  one  does  exist,  the  associated  road-polygons  are  drawn 
immediately  after  the  terrain.  This  insures  that  hidden  surface  elimination  occurs 
for  the  roads  as  well  as  the  terrain.  A  photograph  of  terrain  which  includes  some 
sections  of  roads  can  be  seen  in  Chapter  VII,  Figure  7.1). 
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IX.    FOG-M  SIMULATOR  USER'S  GUIDE 

A.  OVERVIEW 

This  section  of  the  report  is  a  user's  guide  to  running  the  FOG-M  simulator. 
The  simulator  was  built  to  be  largely  self  documenting.  Instructions  are  clearly- 
displayed  on  the  screen,  including  diagrams  which  serve  as  a  reminder  of  the 
functions  of  the  various  controls.  A  knowledge  of  the  logon  procedure  for  the 
IRIS  workstation  and  the  basic  commands  of  the  UNIX  operating  system  is 
assumed. 

B.  STARTING  THE  SIMULATION 

To  start  the  simulation,  logon  to  the  IRIS  workstation  and  use  the  UNIX  cd 
command  to  change  to  the  directory  containing  the  simulation.  Currently  the 
simulation  is  in  the  directory  /work/terrain.    Therefore  issue  the  command: 

cd  /work/terrain 
Next,  start  execution  of  the  simulation  by  typing  the  command  fogm.  A 
welcome  screen  will  appear  on  the  display  as  shown  in  Figure  9.1.  Pressing  all 
three  of  the  mouse  buttons  simultaneously  will  stop  the  program  and  return 
to  the  UNIX  command  level.  This  option  of  pressing  all  three  buttons  to  exit  is 
available  at  any  time  during  the  execution  of  the  program.  Pressing  the  middle 
mouse  button  advances  the  display  to  the  next  screen  of  instructions.  When  the 
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user  has  advanced  through  the  welcome  screen  and  the  two  instruction  screens 
(Figures  9.2  and  9.3)  he  is  presented  with  a  display  showing  a  two-dimensional 
contour  map.    This  is  the  prelaunch  phase  of  the  simulation. 

C.     PRELAUNCH  CONTROLS 

The  purpose  of  the  prelaunch  phase  is  to  allow  the  user  to  designate  a  missile 
launch  position  and  a  suspected  target  location  position.  In  effect,  the  user 
describes  an  initial  flight  path  for  the  missile. 

1.      The  Prelaunch  Display 

The  prelaunch  display  is  divided  into  three  sections  as  shown  in  Figure 
9.4.  The  upper  right  corner  of  the  display  contains  an  instruction  box  which 
summarizes  the  functions  of  the  mouse  buttons  for  this  phase.  The  lower  right 
corner  contains  a  prelaunch  statistics  box.  The  meanings  of  the  various  items 
within  the  statistics  box  are  explained  below.  The  majority  of  the  display  is 
occupied  by  a  two-dimensional  contour  map.  Each  of  the  square  grids  on  the 
contour  map  represents  a  one  square  kilometer  area.  The  colors  on  the  map  can 
be  interpreted  as  follows.  Green  areas  indicate  terrain  that  is  covered  with 
vegetation  that  is  greater  than  one  meter  high.  Brown  areas  indicate  terrain 
where  the  vegetation  is  less  than  one  meter  high.  Within  each  of  the  color 
categories,  the  elevation  of  the  terrain  is  indicated  by  the  intensity  of  the  color, 
with  the  brighter  colors  representing  the  higher  elevations. 
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2.  Selecting  the  Launch  Position 

The  launch  position  must  be  selected  first.  To  select  the  launch  position, 
use  the  mouse  to  move  the  red  arrow  cursor  to  the  desired  location  on  the  contour 
map.  As  the  cursor  is  moved,  the  UTM  coordinates  of  the  current  cursor  location 
are  shown  in  the  Launch  Position  field  of  the  statistics  box.  These  coordinates 
can  be  used  when  a  more  accurate  selection  of  the  launch  position  is  required  than 
is  obtainable  from  the  contour  map  alone.  When  the  cursor  is  in  the  desired 
position,  press  the  left  mouse  button  to  lock  in  that  position.  A  blue  circle  will 
appear  on  the  contour  map  showing  the  position  selected  and  the  workstation  will 
"beep,"  confirming  the  selection.  The  launch  position  can  be  changed  any  time 
before  the  launching  of  the  missile  by  simply  moving  to  the  new  desired  location 
and  pressing  the  left  mouse  button. 

3.  Selecting  the  Target  Position 

The  target  position  can  only  be  selected  after  a  launch  position  has  been 
set.  After  the  launch  position  has  been  selected,  moving  the  cursor  over  the 
contour  map  produces  the  following  effects: 

-  The  UTM  coordinates  of  the  current  cursor  position  are  shown  in  the  Target 
Location  field  of  the  statistics  box. 

-  A  ''rubber  band"  line  is  drawn  on  the  contour  map  from  the  launch  position 
to  the  current  cursor  location.  This  line  represents  the  flight  path  the  missile 
would  take  if  the  current  cursor  position  was  selected  as  the  target  location. 

-  The  direction  and  length  of  the  flight  path  represented  by  the  above  line  are 
displayed  in  the  statistics  box  in  the  Heading  and  Distance  fields  respectively. 

Once  the  cursor  is  at  the  desired  target  location,  press  the  right  mouse  button 
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to  lock  in  the  position.    A  red  circle  will  appear  on  the  contour  map  showing  the 
selected  location  and  the  workstation  will  ''beep,"  confirming  the  selection. 

The  missile  is  now  ready  for  launch.    The  target  location  can  be  changed 
any  time  before  launch  by  simply  moving  the  cursor  to  the  desired  new  location 
and  pressing  the  right  mouse  button. 
4.      Launching  the  Missile 

Launching  can  not  take  place  until  both  a  launch  and  target  location 
have  been  selected.  If  the  launch  and  target  locations  selected  are  acceptable,  the 
missile  is  "launched"  by  pressing  the  middle  mouse  button. 

If  this  is  the  initial  launch  of  this  execution  of  the  program,  a  several 
(three  to  four)  minute  delay  will  follow  during  which  calculations  are  done  to 
construct  the  upcoming  three-dimensional  scenes.  Again,  this  delay  only  occurs 
during  the  first  launch  of  any  execution.  Subsequent  launches  proceed  with  no 
delay.  During  this  delay,  a  countdown  will  appear  in  the  bottom  of  the  statistics 
box.    Launch  occurs  when  the  countdown  reaches  zero. 

D.     IN-FLIGHT  CONTROLS 
1.      The  In-Flight  Display 

After  the  missile  is  launched,  the  display  changes  to  the  in-night  display 
shown  in  Figure  9.5.    The  left  side  of  the  display  contains: 

-  A  three-dimensional  view  of  the  terrain  as  seen  from  the  missile's  camera. 

-  A  slider  bar  scale  along  the  bottom  edge  indicating  the  camera  pan  angle. 
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-  A  slider  bar  scale  along  the  left  hand  edge  indicating  the  camera  tilt  angle. 

-  A  box  in  the  lower  left  corner  containing  either  the  word  DESIGNATE  or 
REJECT.  The  word  DESIGNATE  in  this  box  indicates  that  the  missile  is 
not  locked  on  to  a  target  and  is  waiting  for  a  command  to  designate  one. 
The  word  REJECT  indicates  that  the  missile  is  locked  on  to  a  target  and  is 
waiting  for  a  command  to  reject  that  target. 

-  Cross  hairs  used  to  sight  the  camera  onto  a  target. 

The  upper  right  corner  of  the  display  contains  a  scaled  copy  of  the  contour  map 
seen  in  the  prelaunch  phase.  The  red  arrow  superimposed  on  the  contour  map 
shows  the  missile's  current  position  (the  tail  of  the  arrow)  and  its  direction  of 

flight.  The  red  rectangle  on  the  map  indicates  that  area  of  the  terrain  that  is 
currently  being  shown  in  the  three-dimensional  display. 

The  middle  right  section  of  the  display  contains  four  indicators  which 
show  the  following: 

-  The  speed  of  the  missile  in  knots. 

-  The  direction  the  missile  is  traveling  in  degrees. 

-  The  height  of  the  missile  above  ground  level  (AGL)  in  feet. 

-  The  height  of  the  missile  above  mean  sea  level  (MSL)  in  feet. 

-  A  slider  bar  indicating  the  zoom  setting  of  the  camera  in  degrees. 

The  lower  right  section  of  the  display  contains  a  summary  of  the  functions 
performed  by  the  mouse  and  dials.  These  are  explained  further  below.  The  in- 
flight phase  continues  until  the  missile  impacts  a  designated  target  or  all  three 
mouse  buttons  are  pressed  simultaneously  (to  stop  the  execution  of  the 
simulation). 
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2.  Controlling  the  Camera 

The  ranges  and  initial  values  of  the  camera's  functions  are  shown  in 
Table  9.1.    All  of  the  camera's  functions  are  controlled  with  the  mouse. 

-  To  pan  the  camera,  move  the  mouse  left  or  right  as  needed. 

-  To  tilt  the  camera,  move  the  mouse  up  or  down  as  needed. 

-  To  zoom  in  to  a  tighter  field  of  view,  press  the  left  mouse  button. 

-  To  zoom  out  to  a  wider  field  of  view,  press  the  right  mouse  button. 

3.  Controlling  the  Missile  Flight 

The  missile  can  be  controlled  by  changing  its  direction,  speed,  and 
altitude.  The  ranges  and  initial  values  of  each  of  the  flight  parameters  is  shown 
in  Table  9.2.  The  missile  flight  parameters  are  controlled  by  using  the  dials  on 
the  IRIS's  button/dial  box  (see  Figure  9.6).  Dial  zero  (lower  left)  controls  the 
missile's  direction,  dial  one  (lower  right)  controls  the  missile's  altitude,  and  dial 
two  (above  dial  zero)  controls  the  missile's  speed.  Refer  to  the  display's  control 
TABLE  9.1  CAMERA  CONTROL  RANGES  AND  INITIAL  VALUES 


Control 

Range 

Initial  Value 

Maximum 

Minimum 

Pan 

Tilt 
Zoom 

25  degrees  right 
25  degrees  down 
55  degrees 

25  degrees  left 
15  degrees  up 
8  degrees 

0  degrees 

15  degrees  down 

55  degrees 

TABLE  9.2  MISSILE  CONTROL  RANGES  AND  INITIAL  VALUES 


Control 

Range 

Initial  Value 

Maximum 

Minimum 

Altitude 

Speed 

Direction 

10,000  MSL 
400  kts 
359.9  degrees 

200  AGL 

0  kts 

0  degrees 

200  AGL 

200  kts 

From  prelaunch 
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Figure  9.6   IRIS  Dial  Box  Fuctions 
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summary  box  for  a  reminder  of  each  dial's  purpose  and  location  during  flight. 
The  controls  are  used  as  follows: 

-  Direction  of  flight  -  Turning  dial  zero  clockwise  turns  the  missile  to  the 
right.  Turning  it  counterclockwise  turns  it  to  the  left.  The  missile  will  move 
freely  through  the  360  degree  mark  so  that,  for  example,  turning  the  missile 
right  two  degrees  from  a  heading  of  359  degrees  will  produce  a  heading  of 
001. 

-  Altitude  -  Turning  dial  one  clockwise  increases  the  missile's  altitude  up  to 
the  maximum  of  10,000  feet  MSL.  Turning  the  dial  counterclockwise 
decreases  the  missile's  altitude.  The  simulator  will  not  allow  an  altitude  to 
be  selected  that  is  less  than  200  feet  above  ground  level. 

-  Speed  -  Turning  dial  two  clockwise  increases  the  missile's  speed,  while 
counterclockwise  decreases  the  speed. 

4.      Designating  and  Rejecting  Targets 

The  middle  mouse  button  is  used  to  designate  (lock  on  to)  and  reject 

(release  the  lock  on)  targets.    When  the  missile  is  not  locked  on  to  a  target  the 

word   DESIGNATE   will    appear   in    the   lower   left    corner   of  the   display.     To 

designate  a  target,  center  the  target  within  the  cross  hairs  and  press  the  middle 

mouse  button.    In  order  for  the  missile  to  lock  on,  some  portion  of  the  target 

must   be  in  the  center  of  the  cross  hairs.     If  the  designation  is  successful,  the 

workstation  will   "beep"  and  word  REJECT  will  appear  in  place  of  the  word 

DESIGNATE    on    the    display.     Once    a    target    is    designated    the    missile    will 

automatically  adjust  its  heading  and  altitude  to  home  in  on  the  selected  target. 

An  explosion  is  displayed  after  impact  with  the  target  occurs.    The  user  is  then 

returned  to  the  prelaunch  phase  of  the  simulation  to  begin  another  launch. 
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A  locked  on  target  can  be  rejected  and  missile  flight  control  returned  to 
the  user  by  pressing  the  middle  mouse  button  any  time  before  impact  with  the 
target  occurs.  The  workstation  will  respond  with  a  "beep"  and  the 
reject/designate  box  will  again  show  the  word  DESIGNATE.  The  missile  is  now 
ready  to  accept  the  designation  of  a  new  target. 
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X.   CONCLUSIONS  AND  RECOMMENDATIONS 

A.     LIMITATIONS 

There  are  several  limitations  to  the  flight  simulator  presented  in  this  study. 
First,  a  trade-off  had  to  be  made  between  resolution  and  frame  update  (display) 
speed.  Even  though  data  was  available  at  a  resolution  of  twelve  and  one-half 
meters,  the  simulator  uses  one  hundred  meter  resolution  in  order  to  achieve  an 
acceptable  frame  update  rate. 

Second,  the  simulator's  flight  is  confined  to  a  ten  kilometer  square  area.  Any 
ten  kilometer  square  area  of  the  DTED  file  can  be  used  during  a  run  of  the 
simulation,  but  the  simulator  must  be  exited  before  switching  to  a  new  area.  This 
limitation  is  not  too  restrictive  for  the  current  range  of  the  FOG-M,  but  may  be 
inadequate  if  the  range  of  the  missile  is  increased  as  planned. 

Third,  road  data  is  available  in  a  format  usable  by  the  simulator  for  only  one 
10  kilometer  square  area.  Since  access  routines  were  not  developed  for  the  DFAD 
data  file,  roads  must  be  digitized  by  hand. 

Fourth,  the  simulator  does  not  model  any  of  the  missile's  flight  dynamics.  As 
stated  earlier,  this  limitation  was  imposed  only  because  of  development  time 
constraints.  It  is  felt  that  the  dynamics  can  be  acceptably  modeled  without 
adversely  affecting  the  performance. 
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B.  FUTURE  RESEARCH  AREAS 

A  follow-on  to  this  project,  which  will  provide  more  realistic  targets  and 
allow  viewing  of  the  scene  as  seen  from  inside  any  of  them,  is  currently  underway 
at  the  Naval  Postgraduate  School.  The  project's  plans  are  to  use  the  Ethernet  to 
allow  several  workstations  to  take  part  in  the  simulation  simultaneously.  Each 
workstation  will  control  one  weapon  (a  target  or  the  missile)  and  its  monitor  will 
display  the  scene  as  viewed  from  that  weapon. 

Work  is  also  underway  at  the  Naval  Postgraduate  School  in  the  use  of 
digitized  photographic  images  on  the  IRIS.  This  work  could  possibly  be 
incorporated  into  the  FOG-M  project  through  the  use  of  digitized  target  images, 
digitized  cultural  features,  or  digitized  textures  for  the  terrains. 

Another  possible  research  area  is  the  addition  of  various  environmental  effects 
into  the  simulation.  These  include  clouds,  smoke,  and  rain,  which  affect  the 
camera's  view  by  reducing  visibility,  and  also  dust,  which  aids  the  missile 
operator  in  acquiring  moving  targets. 

Much  work  could  be  done  in  the  area  of  the  missile's  flight  dynamics.  The 
goal  would  be  to  provide  an  acceptably  accurate  model  without  too  much  of  a 
sacrifice  in  speed. 

C.  SUMMARY  AND  CONCLUSIONS 

The  project  has  proven  the  practicality  and  feasibility  of  building  a  low-cost 
flight  simulator  with  commercial,  off-the-shelf  hardware.  With  a  relatively  small 
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investment  of  time  and  funds,  a  simulator  with  significant  capabilities  was 
developed.  As  the  speed  and  power  of  graphics  hardware  increases,  even  more 
realistic  displays  at  faster  update  rates  will  be  possible. 
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APPENDIX  A 


MODULE  DESCRIPTIONS 


BUILD   ROAD.C 


Input: 
Output: 
Side  Effects: 


Description: 


None. 

None. 

Modifies  the  global  array  road ,  an  array  of  graphical  objects,  where 
each  object  contains  the  polygons  representing  the  road  in  a 
particular  gridsquare. 

Build  road  reads  the  file  road  width  and  centerline  information 
from  the  file  Road. data  and  constructs  polygons  which  represent 
the  road.  The  polygons  are  stored  in  the  array  of  graphical  objects 
road.  A  more  detailed  discussion  of  building  the  roads  is  contained 
in  Chapter  VIII. 

BUILDTERRAIN.C 

Input:  None. 

Output:  None. 

Side  Effects:      Buildttrrain  modifies  the  global  arrays  savetriangle  and  gridcolor . 

Description:  Buildttrrain  reads  terrain  height  information  from  the  global  array 
gridpixel  and  constructs  the  terrain  as  a  set  of  planar  triangles. 
The  details  of  constructing  the  triangles  and  the  format  of  the 
savetriangle  and  gridcolor  arrays  can  be  found  in  Chapter  VI. 


COLORRAMP. C 


Input: 


Output: 
Side   Effects: 


The  inputs  to  colorramp  are  two  booleans,  greyscale  and  init.  If 
greyscale  is  TRUE,  the  terrain,  sky,  and  target  colortable  entries 
are  defined  in  shades  of  grey  to  produce  a  black-and-white  image. 
If  greyscale  is  FALSE,  the  terrain  colors  are  green,  the  sky  is  blue, 
and  targets  are  brown.  Init  is  set  to  TRUE  when  this  routine  is 
initially  called,  so  that  every  entry  in  the  colortable  is  defined, 
including  those  for  terrain,  sky,  targets,  and  writemasked  lines  on 
top  of  the  contour  maps.  Should  the  display  be  switched  between 
color  and  black-and-white,  only  the  terrain,  sky,  and  target  entries 
need  to  be  redefined,  which  is  what  happens  when  init  is  FALSE. 

None. 

Colorramp  changes  the  system's  colortable,  and  thus  determines 
the  colors  that  appear  on  the  display  for  the  images  drawn  by 
other  routines. 
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Description:  Colorramp  is  called  by  the  main  program  fogm  as  part  of  the 
initialization  that  takes  place  before  the  flying  loop  is  entered.  At 
that  point,  greyscale  is  set  to  its  default  value  (usually  FALSE, 
indicating  color  images)  and  init  is  TRUE.  The  readcontrols 
routine  also  calls  colorramp  to  toggle  the  display  image  between 
color  and  black-and-white,  based  on  the  position  of  one  of  the 
dials.  This  call  is  made  with  the  desired  value  for  greyscale  and 
with  init  FALSE.  Colorramp  uses  the  IRIS  routine  mapcolor  to 
directly  update  the  colortable  for  the  contour  map  colors,  and  calls 
the  user  written  routine  gammaramp  to  define  appropriately 
shaded  ranges  of  the  greens  and  browns  (or  greys)  used  for  the 
terrain  and  targets. 


COMPASS. C 

Input:  Compass   takes  as  input  a  float,   direction,  which  is  an  angle  in 

radians. 

Output:  Compass  returns  a  float  which  is  the  compass  direction  in  degrees 

corresponding  to  the  input  direction. 

Side  Effects:      None. 

Description:  The  function  Compass  converts  an  radian  angle  measured  using 
the  standard  mathematical  convention,  and  converts  it  to  a  degree 
angle  measured  using  the  standard  navigational  convention. 


DISP    TERRAIN. C 

Input:  Display  terrain  takes  eleven  inputs:    the  X,  Y,  and  Z,  coordinates 

of  the  missile  position  VX,  VY,  and  VZ\  the  X,  F,  and  Z 
coordinates  of  the  camera's  look-at  position  PX,  PY,  PZ;  the  field 
of  view  angle  (camera  zoom  value),  FOVY;  and  the  X  and  Z 
ranges  of  gridsquares  to  be  displayed,  FIRST  X,  FIRST  Z, 
LAST  X  and  LAST  Z. 

Output:  None. 

Side  Effects:      None. 

Description:  Disp  terrain  outputs  a  frame  of  the  terrain  scene  to  the  monitor 
using  a  hidden  surface  algorithm.  The  scene  contains  terrain, 
roads,  and  targets.  Details  of  the  hidden  surface  algorithm  can  be 
found  in  Chapter  VI. 
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DIST    TO   LOS. C 

Input:  Dist  to  los  takes  seven  inputs:    the  X,  Y,  and  Z  coordinates  of  the 

start  of  a  line  segment;  the  X,  Y,  and  Z  coordinates  of  the  end 
point  of  a  line  segment;  and  three  dimensional  array,  pt,  which 
contains  the  coordinates  of  a  point. 

Output:  Dist  to  los    returns   a   float   which   is   the   perpendicular  distance 

from  the  input  point,  pt,  to  the  input  line. 

Side  Effects:      None. 

Description:       Function  which  computes  the  perpendicular  distance  from  a  point 
to  a  line  in  three-space. 


DO   BOUNDARY. C 

Input:  Do   boundary  takes  the  following  inputs: 

-  An  integer  Bound  type  which  is  interpreted  as: 

0  -  a  diagonal  boundary 

1  -  a  horizontal  boundary 

2  -  a  vertical  boundary 

-  An  integer  which  triangle  that  is  interpreted  as: 

0  -  the  lower  triangle  of  the  gridsquare. 

1  -  the  upper  triangle  of  the  gridsquare. 

-  The  indices,  xgrid  and  zgrid,  of  the  gridsquare  for  which  the  road 
is  being  constructed. 

-  The  coordinates  of  the  start  point  of  the  boundary  stored  in  a 
three  dimensional  array,  bound  start. 

-  The  coordinates  of  the  end  point  of  the  boundary  stored  in  a 
three  dimensional  array,  bound  end. 

-  The  coordinates  of  the  start  point  of  the  left  side  of  the  road 
stored  in  a  three  dimensional  array,  left   start. 

-  The  coordinates  of  the  end  point  of  left  side  of  the  road  stored  in 
a  three  dimensional  array,  left    end. 

-  The  coordinates  of  the  start  point  of  the  right  side  of  the  road 
stored  in  a  three  dimensional  array,  right   start. 

-  The  coordinates  of  the  end  point  of  right  side  of  the  road  stored 
in  a  three  dimensional  array,  right   end. 

-  A  boolean,  start  corner  flag,  which  is  TRUE  if  the  gridsquare 
corner  at  the  boundary's  start  is  ALREADY  in  the  road  polygon 
array,  FALSE  otherwise. 

-  A  boolean,  end  corner  flag,  which  is  TRUE  if  the  gridsquare 
corner  at  the  boundary's  end  is  ALREADY  in  the  road  polygon 
array,  FALSE  otherwise. 

-  The  partially  complete  road  polygon  array,  road  poly. 
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-  An  integer,  vertex  cnt,  that  is  the  number  of  vertices  currently  in 
the  road  poly  array. 

Output:  Do   boundary  outputs  the  following: 

-  start   corner  flag  (see  Inputs  for  a  description) 

-  end  corner  flag  (see  Inputs  for  a  description) 

-  road  poly,  the  road  polygon  array  with  the  vertices  along  this 
boundary  added. 

-  vertex  cnt  (see  Inputs  for  a  description) 

Side  Effects:      None. 

Description:  Do  boundary's  purpose  is  to  find  all  the  intersections  of  the  road's 
left  and  right  sides  with  the  input  boundary  of  a  gridtriangle.  As 
an  intersection  is  found  the  point  is  put  into  a  temporary  array. 
After  all  the  intersections  are  found  for  the  boundary  the  points  in 
the  temporary  array  are  sorted  then  added  to  the  existing 
road  poly  array.  The  order  of  the  sorting  is  such  that  the  resulting 
road  poly  array  will  be  ordered  counterclockwise.  See  Chapter 
VIII  for  a  detailed  description  of  building  the  roads. 

EDIT   INDBOX. C 

Input:  The  inputs  to  edit   indbox  are  the  name  of  the  indicator  object,  the 

tags  within  that  object  for  each  of  the  indicators,  and  current 
values  for  the  following  missile  parameters:  X,  F,  and  Z  position 
coordinates,  pan,  tilt,  and  zoom  angles,  and  design  ate /reject 
status. 

Output:  None. 

Side  Effects:  Since  edit  indbox  changes  the  indicator  object,  it  has  the  side 
effect  of  changing  the  display  when  the  indicator  object  is  next 
called  and  displayed. 

Description:  The  indicator  object  is  edited  between  each  display  frame  so  that 
the  heads-up  display  and  the  indicator  box  indicators  show  the 
current  values  for  the  missile's  speed,  heading,  altitude,  camera 
pan  angle,  camera  tilt  angle,  camera  field  of  view  (zoom),  and 
designate/reject  status.  The  input  speed,  heading,  and  MSL 
altitude  ( Y  position  coordinate)  are  converted  to  strings  for 
display.  AGL  altitude  is  calculated  as  the  difference  between  MSL 
altitude  and  the  elevation  of  the  ground  directly  below  the  missile 
as  obtained  from  gnd  level  with  the  .Y  and  Z  position  coordinates 
as  input.  The  boolean  designate  determines  whether 
"DESIGNATE"  or  "REJECT"  is  printed  in  the  lower  left  corner 
of  the  terrain  display.  Finally,  the  positions  of  the  tilt,  pan,  and 
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zoom  indicators  are  calculated  from  the  missile  parameters.  The 
equations  in  the  code  have  been  simplified  to  avoid  excess 
computation;  the  derivations  are  given  below. 

The  x  screen  coordinate  of  the  zoom  (field  of  view,  or  fov)  indicator 
is  fixed.  The  y  screen  coordinate  varies  from  200  (at  8  fov)  to  70 
(at  55  fov).  The  input  missile  parameter  zoom  is  in  tenths  of 
degrees,  and  thus  ranges  from  80  to  550.  The  y  coordinate  is 
determined  from  Equation  A.l. 


y  =  200 


zoom 


10 


200  -  70 


55-8 


(A.l) 


zoom 


0.2766  +  222.128 


Likewise,  the  screen  x  coordinate  of  the  tilt  indicator  is  fixed,  while 
the  y  coordinate  varies  from  680  (at  +25  tilt)  to  50  (at  —25  tilt). 
The  input  missile  parameter  tilt  is  in  radians,  and  is  converted  to 
degrees  by  multiplying  it  with  the  RTOD  (Radians  TO  Degrees) 
constant  from  the  header  file  fogm.h.  The  y  coordinate  of  the  tilt 
indicator  is  calculated  as  shown  in  Equation  A. 2. 


y  =  50  +■ 


(tilt  *DTOR)  +  25 


680  -  50 


25 


25 


(A.2) 


tilt   *  721.92682  +  365 


The  pan  slider  bar  is  horizontal,  so  the  y  coordinate  is  fixed,  and 
the  x  coordinate  ranges  from  120  (at  -25    pan)  to  750  (at   +25 
pan).  Like  tilt,  the  pan  value  is  in  radians  and  must  be  converted 
to  degrees.  The  pan  indicator  x  coordinate  is  given  by  Equation 
A.3. 


x  =  750 


(pan  *  DTOR)  +  25 


750  -  120 


25 


25 


(A.3) 


pan  *  -721.92682  +  435 
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EXPLOSION. C 

Input:  None. 

Output:  None. 

Side  Effects:      None. 

Description:  The  explosion  routine  simulates  the  effect  of  a  missile  destroying  a 
target  by  rapidly  flashing  a  succession  of  red,  black,  and  yellow 
screens.  One  buffer  is  kept  black  to  pronounce  the  flash  effect,  and 
the  other  buffer  is  alternately  cleared  to  red,  yellow,  red,  yellow, 
and  red.  A  short  pause  with  a  cleared,  black  screen  is  provided 
before  the  routine  exits. 


FOGM.C 

Input: 


Output: 
Side  Effects: 
Description: 


Fogm  is  the  name  given  to  the  main  program  in  the  simulator.  It 
has  no  parameters,  but  gets  data  from  its  header  files  and  through 
the  readdata  routine.  Interactive  input  is  also  received  vial  the 
readcontrols  routine. 

None. 


N 


one. 


The  fogm  program  consists  of  global  variable  declarations,  local 
variable  declarations,  system  initializations,  an  active  loop,  and 
some  exit  housekeeping.  The  initialization  portion  includes  reading 
in  the  DMA  elevation  data,  making  network  connection  (if  in  use), 
setting  the  IRIS  display  configuration,  defining  the  color  table 
entries,  building  all  of  the  graphical  objects  used  in  the  displays, 
and  computing  the  lighting  and  position  of  the  polygons  used  to 
produce  the  terrain  image.  Within  the  active  loop  is  some 
additional  initializations  and  the  flying  loop.  In  the  active  loop 
initializations,  the  dial  and  mouse  controls  are  reset  to  their  initial 
defaults,  and  the  display  buffers  are  loaded  with  the  images  that 
remain  unchanged  during  flight  simulation  (the  contour  map  and 
the  legend/instruction  box).  Control  is  then  passed  to  the  flying 
loop,  which  produces  the  flight  simulation  images  until  either  a 
target  is  hit  or  the  simulation  exit  command  is  received.  If  a  target 
was  hit,  an  explosion  is  displayed  and  the  pre-launch  phase  of 
designating  launch  and  target  positions  is  re-entered.  If  all  three 
mouse  buttons  have  been  pressed,  the  display  is  cleared  and 
various  system  parameters  are  reset  to  provide  a  graceful  exit  from 
the  simulator. 
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The  flying  loop  contains  the  subroutine  calls  that  produce  the 
simulation  of  flight.  First,  the  mouse  and  dials  are  checked  for 
control  input.  Then  the  targets',  missile's,  and  lookat  reference 
point's  positions  are  all  updated  based  on  the  elapsed  time  since 
the  previous  frame  and  the  appropriate  speeds.  View  bounds  is 
called  to  determine  which  one  kilometer  grid  squares  are  in  view, 
and  then  the  indicators  are  all  updated  to  show  the  new  control 
values,  missile  statistics,  and  view  area.  The  main  display  routine 
then  draws  the  appropriate  sections  of  the  terrain,  plus  cultural 
features  and  targets  where  appropriate.  Finally,  the  updated 
indicator  objects  are  drawn,  and  the  display  buffers  are  swapped  to 
display  the  newly  created  image. 


GAMMARAMP.C 

Input:  The   inputs  to   gammaramp   are  a  correction  factor,  a  color  table 

starting  index,  the  number  of  color  table  entries  (shades)  to  be 
defined,  red,  green,  and  blue  intensities  for  the  brightest  color  to  be 
defined,  and  finally,  red,  green,  and  blue  intensities  for  the  darkest 
color  to  be  defined. 

Output:  None. 

Side  Effects:  Gammaramp  has  the  side  effect  of  defining  entries  in  the  system 
color  table. 

Description:  Displayed  colors  do  not  correspond  linearly  to  the  numeric  red, 
green,  and  blue  intensity  values  that  are  used  to  produce  them.  If  a 
range  of  colors  (0  ..  #colors-l)  is  defined  in  the  straightforward  way 
with  a  uniform  increment,  the  intensity  of  the  n  color  (/  )  is 
given  by  Equation  A. 4,  and  the  bright  colors  will  appear  more 
widely  spaced  than  the  dark  colors. 

MaxI  -  Mini 

In  =  n  *  +  Mini  (A.4) 

§  colors 

Gammaramp  avoids  this  by  using  a  power  function  to  increase 
spacing  between  the  dark  colors'  intensity  values  and  to  decrease 
the  intensity  increment  as  the  colors  get  brighter.  The  strength  of 
the  correction  is  determined  by  a  value  7,  which  is  constant  for  a 
given  range,  but  must  be  experimentally  determined  for  each  range 
that  differs  in  color  or  number  of  colors.  FOG-M  uses  a  7  value  of 
1.5.  The  intensity  of  the  n  color  in  a  gammaramp  created  table  is 
given  by  Equation  A. 5. 
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/  = 

n 


§  colors  -  1  , 


(MaxI  -  Mini)  +  Mini 


(A.5) 


GET   TGT   POS.C 


Input: 


Output: 


Side   Effects: 


Description: 


The  input  to  get  tgt  pos  is  a  socket  number  for  Ethernet 
communication  (if  in  use),  a  boolean  indicating  designate/reject 
status,  the  index  of  the  currently  designated  target,  and  the 
"name"  of  the  tank  object. 

Output  is  the  new  X,  Y,Z  position  coordinates  of  the  currently 
designated  target. 

Get  tgt  pos  updates  several  global  data  structures.  It  sets  the 
number  of  target  images,  updates  the  target  position  arrays,  and 
updates  the  array  of  target  object  names. 

The  primary  purpose  of  get  tgt  pos  is  to  move  the  targets  in  the 
simulation.  If  the  networking  capability  is  in  use,  the  target 
positions  for  the  next  frame  are  received  over  the  network.  When 
networking  is  not  in  use,  targets  are  moved  at  a  set  speed  of  fifteen 
knots,  and  reverse  course  when  they  reach  the  boundaries  of  the 
ten  kilometer  square  terrain  area.  As  explained  in  Chapter  VII,  an 
array  of  graphical  objects  is  defined  to  match  one  object  per  one 
hundred  meter  square  of  terrain,  and  this  array  is  also  used  as 
booleans  to  indicate  the  presence  or  absence  of  targets  in  the  one 
hundred  meter  grid  square.  Get  tgt  pos  begins  by  removing  each 
target  from  this  array.  New  target  positions  are  calculated  or 
received  over  the  network.  If  one  of  the  targets  has  been  "locked- 
onto,"  its  new  position  is  returned  to  be  used  as  the  current  aim 
point  for  the  missile.  This  is  easily  determined  if  networking  is  off 
because  the  designated  target's  index  remains  the  same  and  the 
new  position  can  be  directly  accessed.  The  index  correspondence  is 
not  guaranteed  when  networking,  so  the  index  of  the  new  target 
whose  coordinates  are  closest  to  the  old  targeted  point  is  used. 

Targets  that  straddle  a  one  hundred  meter  grid  square  boundary 
must  be  drawn  on  top  of  both  (or  possibly  all  four)  grid  squares  in 
order  to  avoid  being  partially  obscured  by  whichever  square  is 
drawn  last.  (The  target  must  be  drawn  immediately  after  the  grid 
square  on  which  it  rests  to  ensure  that  the  target  will  be  obscured 
when  it  should  be  by  terrain  drawn  in  the  foreground.)  Since  the 
calculation  of  boundary  intersection  requires  several  trigonometric 
functions  plus  an  allowance  for  the  distance  between  the  center  of 


113 


the  tank  and  its  boundaries  (which  varies  with  the  direction  of  the 
tank),  a  simplifying  algorithm  is  used.  If  the  tank  is  close  enough 
to  a  boundary  that  the  most  distant  part  of  the  tank  might  cross 
the  boundary,  the  target  is  also  drawn  after  the  adjoining  grid 
square(s)  (see  Figure  7.3).  This  is  done  by  adding  a  "new"  target 
to  the  array  of  target  objects.  The  "new"  target  object  is  drawn  at 
the  exact  same  location  in  the  three-dimensional  terrain,  but  it  is 
drawn  after  a  different  one  hundred  meter  grid  square,  so  it  will 
have  different  target  object  array  indices,  and  be  in  a  separate 
target  object. 

After  all  of  the  targets  (originals  and  boundary  copies)  have 
updated  positions  and  target  object  array  indices,  objects  are 
added  to  the  target  object  array  as  described  in  Chapter  VII.  This 
array  is  then  used  by  the  terrain  display  routine  to  actually  draw 
the  targets. 


GND   LEVEL. C 

Input:  Gnd  level  takes  as  inputs  the  X  and  Z  coordinates  of  the  point  for 

which  the  elevation  is  desired. 

Output:  Gnd  level  returns  a  float  which  is  the  elevation  at  point  X  and  Z. 

Side  Effects:      None. 

Description:  Gnd  level  computes,  through  interpolation,  the  scaled  elevation  of 
any  point  within  the  terrain  boundaries.  A  calculation  is  done  to 
determine  which  gridtriangle  contains  the  point.  Then,  using  the 
known  elevations  at  the  vertices  of  the  triangle,  the  elevation  of  the 
point  is  found. 


IN    THIS    POLY.C 

Input:  In  this  poly  takes  the  following  inputs: 

-  An  array  of  points,  polygon,  which  define  a  polygon.  (Note:  only 
the  X  and  Z  coordinates  of  the  points  are  used,  the  Y  value  is 
ignored). 

-  An  integer,  num  vertex,  that  is  the  number  of  vertices  in 
polygon. 

-  A  point,  pnt,  that  is  to  be  tested.  (Note:  only  the  X  and  Z 
coordinates  of  the  point  is  used,  the  Y  value  is  ignored). 

Output:  In  this  poly  returns  a  boolean  which  is  TRUE  if  pnt  is  inside  the 

polygon  defined  by  polygon,  FALSE  otherwise. 
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Side  Effects:      None. 

Description:  In  this  poly  is  a  function  which  tests  whether  a  point  is  inside  a 
given  polygon,  where  both  the  point  and  the  polygon  are  in  the  XZ 
plane.  The  algorithm  used  constructs  a  bounding  box  around  the 
polygon.  If  the  point  lies  outside  the  bounding  it  obviously  can 
not  be  inside  the  polygon.  If  the  point  lies  inside  the  bounding  box 
a  further  test  is  made.  A  line  is  constructed  from  a  point  outside 
the  bounding  box  to  the  point  to  be  tested.  Each  of  the  edges  of 
the  polygons  are  then  tested  to  see  if  they  intersect  the  constructed 
line  and  a  count  is  kept  of  the  number  that  do  intersect.  The 
point  lies  inside  the  polygon  if  and  only  if  the  constructed  line 
intersects  an  odd  number  of  the  polygon's  edges. 


INIT    CTRLS. C 


Input: 


Output: 


Side  Effects: 


Description: 


Init  ctrls  takes  as  inputs  the  initial  altitude  of  the  missile,  in  feet; 
the  initial  heading  of  the  missile  in  degrees;  and  a  boolean, 
greyscale,  which  is  TRUE  if  greyscaled  terrain  is  to  be  displayed 
and  FALSE  if  color  terrain  is  to  be  displayed. 

Init  ctrls  has  as  outputs  the  initial  pan  angle  of  the  camera  in 
radians;  the  initial  tilt  angle  of  the  camera  in  radians,  and  the 
initial  zoom  setting  of  the  camera  in  tenths  of  a  degree. 

The  MOUSEX,  MOUSEY,  DIALO,  DIALl,  DIAL2,  and  DIAL3 

valuators  are  set  as  a  result  of  calling  this  routine. 

Init  ctrls's  purpose  is  to  initialize  the  mouse  and  dial  valuators 
used  for  the  operator  controls.  The  initial  altitude,  heading,  and 
greyscale  valuator  settings  are  passed  in  as  inputs.  The  pan,  tilt, 
and  field  of  view  settings  are  read  from  an  "include"  file  and  their 
values  passed  back  as  outputs. 


INIT   IRIS. C 

Input:  None. 

Output:  None. 

Side  Effects:      Calling  this  routine  sets  the  Iris  attributes  and  configures  the  Iris. 

Description:  Init  iris  accomplishes  the  following:  it  puts  the  Iris  into 
doublebuffer  mode,  sets  the  chunksize  (the  minimum  memory 
increment  used  in  objects),  sets  the  monitor  type  to  either  NTSC 
or  HZ60,  and  enables  backface  polygon  removal. 


115 


INIT    TGTS. C 

Input:  None. 

Output:  None. 

Side  Effects:  Init  tgts  always  initializes  the  global  target  object  array  to  all 
zeros.  If  target  data  is  not  being  received  over  the  network, 
init  tgts  also  defines  ten  targets  by  setting  initial  values  in  the 
global  target  counter,  target  position  array,  and  target  direction 
array.  An  auxiliary  function  init  tgt  is  used  to  perform  the  actual 
update  of  the  global  arrays. 


INTERP   ELEV.C 

Input:  Interp   elev   takes   three   inputs,   each   an   array   of  X,    Y,  and   Z 

coordinates,  representing  a  point.  One  array  is  the  start  point  of  a 
line,  the  second  array  is  the  end  point  of  a  line,  and  the  third  array 
is  a  point  along  the  line. 

Output:  Interp   elev  returns  a  float  that  is  the  elevation  value  of  the  point 

along  the  line. 

Side  Effects:      None. 

Description:  Interp  elev  returns  a  float  which  is  the  linear  interpolation  of  the 
Y  (elevation)  coordinate  of  the  point  along  the  line,  based  on  the 
elevations  at  the  start  and  end  points  of  the  line. 


LIGHT   ORIENT. C 

Input: 


Output: 

Side  Effects: 
Description: 


Light   orient  takes  as  inputs  the  following: 

-  An  array  of  coordinates  for  the  polygon. 

-  An  integer,  num.  coords,  the  number  of  coordinates  in  the 
polygon. 

-  The  X,  Y,  and  Z  coordinates  of  a  point  that  is  "behind"  the 
polygon  (an  interior  point). 

-  The  X,  F,  and  Z  coordinates  of  a  light  source. 

-  The  minimum  and  maximum  color  map  indices  to  be  used  for 
this  polygon. 

Light  orient  returns  the  color  map  index  of  the  color  to  use  in 
lighting  this  polygon.  It  also  reorders  the  polygon  array  (if 
necessary)  so  that  the  points  are  ordered  counterclockwise. 

None. 

Light  orient  computes  a  lighting  for  a  polygon  based  on  Lambert's 
cosine   law,  which  states  that  the   intensity  of  the  light  reflected 
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from  an  object  is  proportional  to  the  eos($),  where  $  is  the  angle 
of  incidence  of  the  light  ray.  (see  Figure  5.2).  Light  orient  also 
orders  the  vertices  of  the  polygon  in  a  counterclockwise  fashion  so 
that  backface  polygon  removal  can  take  place  (see  the  module 
description  for  npoly  orient). 


LINE  INTER2.C 


Input: 


Output: 


Side  Effects: 
Description: 


Line   inter2  takes  the  following  inputs: 

-  An  array  containing  the  X  and  Z  coordinates  of  the  start  point  of 
line  one  is  ignored.) 

-  An  array  containing  the  X  and  Z  coordinates  of  the  end  of 
line  one.  (Note:  a  three  element  array  is  used,  but  the  second,  Y 
coordinate,  element  is  ignored.) 

-  An  array  containing  the  X,  F,  and  Z  coordinates  of  the  start  of 
line  two.  (Note:  a  three  element  array  is  used,  but  the  second,  Y 
coordinate,  element  is  ignored.) 

-  An  array  containing  the  X,  Y,  and  Z  coordinates  of  the  end  of 
line  two.  (Note:  a  three  element  array  is  used,  but  the  second,  Y 
coordinate,  element  is  ignored.) 

Line   inter2  returns  as  outputs: 

-  An  array  containing  the  X  and  Z  coordinates  of  the  intersection 
of  line  one  and  line  two.  If  the  lines  do  not  intersect  these  values 
are  undefined  not  considered  in  the  calculation). 

-  An  integer  which  can  be  interpreted  as  follows: 

0  -  the  lines  do  not  intersect. 

1  -  the  lines  intersect,  but  the  intersection  uses  an 
extension  of  at  least  one  of  the  lines  past  its  start  or 
end  points. 

2  -  the  lines  intersect,  and  the  intersection  occurs 
between  the  input  start  and  end  points  of  both  lines. 

None. 

Line  interl  computes  the  point  of  intersection  between  two  lines 
in  the  XZ  plane.  The  type  of  intersection,  as  explained  above  in 
"Output"  is  also  determined.  Throughout  the  routine,  three 
element  arrays  are  used  for  compatibility  with  other  routines.  The 
second,  F,  coordinate  is  not  considered  in  any  of  the  calculations. 


MAKEINDBOX.C 

Input:  None. 
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Output:  Makeindbox  returns  a  graphical  object  "name,"  tags  for  editing  the 

speed,  direction,  altitude,  and  designate/reject  readouts,  and  tags 
for  editing  the  zoom,  pan,  and  tilt  indicators. 

Side  Effects:      None. 

Description:  Makeindbox  generates  a  graphical  object  that  contains  both  the 
indicator  box  in  the  middle  of  the  displays  on  the  right  side  of  the 
screen  and  the  uheads-up"  display  that  is  superimposed  on  the 
terrain  image  (Figure  6.8).  The  object  consists  almost  entirely  of 
straightforward  line  and  character  string  drawing  commands,  but 
there  are  two  interesting  points.  First,  within  a  single  object,  there 
are  two  different  coordinate  systems:  one  for  the  indicators 
superimposed  on  the  terrain,  and  another  for  the  separate  indicator 
box.  This  is  accomplished  with  an  ortho2  call  for  each  coordinate 
system,  and  by  bracketing  each  ortho2  with  pushmatrix  and 
popmatrix  commands.  Note  that  the  heads-up  display  is  truly 
superimposed;  it  is  specified  in  two-dimensional  screen  coordinates 
as  opposed  to  the  three-dimensional  terrain  coordinates. 
The  second  interesting  aspect  is  the  movement  of  the  slider  bar 
indicators.  Drawing  the  indicators  as  polygons  would  require  a 
sequence  of  pushmatrix,  translate,  and  popmatrix  calls  for  each 
indicator,  with  movement  achieved  by  editing  the  translate  call.  To 
avoid  all  of  this  matrix  movement  and  multiplication,  the 
"triangle'1  of  the  indicator  is  actually  an  overlapped  line  that 
"fills"  the  triangle  by  spiraling  inwards.  The  line  is  drawn  relative 
to  the  indicated  point,  with  each  segment  of  the  line  specified  as 
offsets  from  that  initial  point,  rather  than  as  absolute  coordinates 
(Figure  A.l).  Movement  of  an  indicator  triangle  defined  in  this 
way  is  achieved  by  editing  the  parameters  of  a  move2  call  in  the 
object,  which  sets  the  current  graphics  drawing  position  to  the 
indicated  point  on  the  slider  bar  scale.  Makeindbox  is  called  once 
by  fogm  before  the  flying  loop  is  entered,  and  then  the  object  is 
edited  (to  update  the  indicator  values)  and  called  (to  display  it) 
every  frame. 


MAKEINSTRBOX.C 

Input:  None. 

Output:  Makeinstrbox  returns  the  name  of  an  object  to  fogm. 

Side  Effects:      None. 
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Description:  Makeinstrbox  creates  the  object  that  produces  the  display  in  the 
lower  right  of  the  screen  (Figure  6.8)  during  flight  simulation.  This 
display  contains  the  legend  for  the  FOG-M  controls  and  the  flight 
parameters  they  affect.  Makeinstrbox  is  called  once  by  fogm  to 
create  the  object,  and  then  the  object  is  called  twice  per  flight  to 
put  the  image  into  each  buffer.  Note  that  writemasks  are  not 
necessary  as  they  are  with  makemap  and  makenavbox,  because 
nothing  else  writes  to  the  instruction  box  portion  of  the  screen 
during  flight.  The  image  thus  remains  undisturbed  in  the  bitplanes 
despite  the  changes  in  other  screen  areas. 

MAKEMAP. C 

Input:  The  input  to  makemap  is  the  globally  defined  array  of  elevation 

and  vegetation  values,  gridpixel. 

Output:  The  output  from  makemap  is  a  graphical  object  "name,"  which  is 

returned  to  fogm. 

Side  Effects:      None. 

Description:  Makemap  generates  the  object  containing  the  contour  map  and 
grid  that  appear  full  screen  during  the  pre-launch  phase,  and 
appear  in  the  upper  right  corner  of  the  screen  during  flight 
simulation  (Figure  4.1).  The  map  is  produced  using  the 
methodology  described  in  Chapter  IV.  Fogm  calls  the  object 
returned  by  drawcontour  twice,  in  order  to  place  the  map  image  in 
both  buffers.  The  image  is  then  protected  from  overwrite  by  a 
writemask.  Fogm  also  passes  the  object  name  to  prelaunch,  which 
uses  it  in  much  the  same  way  as  fogm. 


MAKESCREENS. C 

Input:  None. 

Output:  Makescreens     returns     an     array     of    objects:     instruction    panel, 

statistics  box,  flight  path  between  launch  and  target  endpoints, 
and  the  three  welcome  screens,  plus  tags  to  update  the  statistics 
and  flight  path. 

Side  Effects:      None. 

Description:       Makescreens  builds  all  of  the  objects  (mostly  screens  of  text)  that 
are  used  by  prelaunch. 


120 


MAKETANK.C 

Input:  None. 

Output:  Maketank  returns  the  name  of  an  object  containing  a  single  tank, 

drawn  around  the  origin. 

Side  Effects:      None. 

Description:  Maketank  builds  a  object  that  consists  solely  of  the  drawing 
commands  to  produce  a  single  tank.  The  tank  is  thirty-two  feet 
long,  ten  feet  high,  and  ten  feet  wide.  Its  center  bottom  is  at  the 
origin  (coordinates  0,0,0),  with  its  left  side  on  the  plane  Z  =  -5,  its 
back  on  the  plane  X  =  -15,  its  bottom  on  the  plane  Y  =  0,  and  it 
faces  to  the  right  along  the  positive  x  axis.  For  each  of  the  twenty 
polygon  faces  that  make  the  tank,  the  X,  Y,  and  Z  coordinates  of 
each  polygon  vertex  are  stored  in  an  array,  passed  to  lightorient, 
and  then  drawn  with  polf ,  the  filled  polygon  drawing  command. 
Lightorient  ensures  the  vertices  are  ordered  counter-clockwise  in 
the  array  (with  respect  to  an  interior  point)  for  backface  polygon 
removal,  and  then  calculates  the  appropriate  color  for  the  polygon 
using  the  same  lighting  model  that  is  used  for  the  terrain  (see 
Chapter  V). 


NEAREST   TGT. C 

Input:  Nearest   tgt   takes  as  inputs  the  X,    F,  and  Z  coordinates  of  the 

missile  position,  and  the  X,   F,  and  Z  coordinates  of  the  camera's 
look-at  position.  (The  end  points  of  the  line  of  sight  vector). 

Output:  Nearest   tgt   returns   as  output   an   integer,   tgt   idx,  which   is   the 

target  index  of  the  target  that  is  closest  to  the  line  of  sight  vector. 

Side  Effects:      None. 

Description:  For  each  of  the  existing  targets,  nearest  tgt  computes  the  distance 
between  the  target  and  the  line  of  sight  vector.  It  returns  the 
index  of  the  target  that  was  found  to  be  closest.  In  the  case  of  two 
targets  which  are  the  same  distance  apart,  the  highest  index  value 
will  be  returned. 


NPOLY   ORIENT. C 


Input: 


Npoly  orient  takes  as  input: 

-  An  integer,  num   coords,  that  is  the  number  of  vertices  in  the 
polygon. 

-  An  array  containing  the  coordinates  of  the  polygon. 

-  The  X,    F,  and  Z  coordinates  of  a  point  that  is  "behind"  the 
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polygon  (an  "interior"  point). 

Output:  Npoly  orient  returns  as  output  an  integer  which  is  interpreted  as: 

1  -  the  vertices  of  the  polygon  are  ordered  clockwise. 

2  -      the     vertices     of     the     polygon     are     ordered 
counterclockwise. 

Side  Effects:      None. 

Description:  Npoly  orient  determines  if  the  polygon  is  ordered  clockwise  or 
counterclockwise  by  computing  two  points:  one  along  the  normal 
vector  and  the  other,  the  same  distance  from  the  polygon,  but 
along  the  vector  in  the  direction  opposite  the  normal.  Next  the 
distance  between  these  points  and  the  "interior"  point  is 
computed.  If  the  "interior"  point  is  closer  to  the  point  along  the 
normal  vector,  the  polygon  is  ordered  clockwise,  otherwise  the 
polygon  is  ordered  counterclockwise. 


PRELAUNCH. C 

Input:  The  input  to  prelaunch  is  two  arrays.  The  first  contains  objects, 

and  the  second  contains  tags  for  editing  those  objects. 

Output:  Prelaunch   returns   the   X,  Y,   and    Z  coordinates  of  the   missile's 

designated  launch  position,  and  the  initial  direction  of  flight  for  the 
missile.  This  direction  is  returned  in  both  radians  and  compass 
degrees  (Figure  7.1). 

Side  Effects:      None. 

Description:  Prelaunch  first  provides  three  screens  of  introductory  information. 
Each  screen  is  an  object  defined  by  makescreens.  After  those,  the 
user  is  presented  with  a  full  screen  contour  map  of  the  ten 
kilometer  by  ten  kilometer  area  available  for  overflight.  Mouse- 
selected  points  define  the  missile's  initial  position  and  direction  of 
flight,  and  are  displayed  on  top  of  the  map.  The  map  is  writemask 
protected,  so  it  is  only  drawn  twice  (once  for  each  buffer)  even 
though  the  flight  path  is  repeatedly  drawn  and  erased  on  top  of  the 
map.  The  flight  path  is  made  to  act  like  a  rubber  band  between 
the  launch  and  cursor  positions  by  repeatedly  editing  of  the 
positions  in  the  object  containing  the  flight  path  line  drawing 
commands.  Once  the  flight  path  is  confirmed,  the  launch  position 
and  heading  are  returned  to  the  fogm  program. 
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RANDNUM. C 

Input:  Randnum  uses  the  global  random  number  seed. 

Output:  Randnum  returns  a  floating  point  random  number. 

Side  Effects:  The  global  seed  value  used  by  randnum  is  updated  during  every 
invocation. 

Description:  Randnum  is  a  linear  congruential  pseudo-random  number 
generator.  The  algorithm  is  a  modified  version  of  the  one  given  by 
Sedgewick  [Ref.  13].  It  uses  a  a  special  piecewise  multiplication 
routine  mult  to  preserve  the  low-order  digits  of  the  newly 
generated  seed  even  in  case  of  overflow.  The  value  returned  is  the 
new  seed,  scaled  to  fall  between  zero  and  one,  inclusive.  The 
random  numbers  are  used  in  fogm  to  vary  the  point  on  the  tank 
that  the  missile  aims  for.  This  simulates  the  variance  in  impact 
point  that  results  from  the  optical  homing  of  the  real  missile. 

RANDSEED. C 

Input:  Randseed  takes  a  long  integer  as  input. 

Output:  None. 

Side  Effects:      Randseed  updates  the  global  random  number  seed  value. 

Description:  The  pseudo-random  number  generator  implemented  in  randnum 
always  returns  the  same  string  of  numbers  when  it  starts  with  a 
given  seed  value.  Randseed  provides  the  means  to  change  that 
initial  seed  value  so  that  different  program  runs  will  have  different 
strings  of  "random"  numbers. 

READCONTROLS.C 

Input:  The  inputs  to   readcontrols   are  the  global   X,  Y,   and   Z   random 

offset  values  for  the  aim  point  on  the  target,  the  current 
designate/reject  status,  and  the  black-and-white  versus  color 
boolean  greyscale. 

Output:  All    of    the    user-commanded    control    values    are    output    from 

readcontrols:  missile  speed,  heading  and  altitude,  camera  pan,  tilt, 
and  zoom  angles,  plus  designate/reject  status,  greyscale  status. 
Readcontrols  also  returns  values  for  the  booleans  that  control  the 
active  and  flying  loops. 

Side  Effects:  When  a  target  is  first  designated,  readcontrols  calls  randnum  and 
updates  the  global  target  aim  offsets  randx,  randy,  and  randz. 
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Description:  Readcontrols  checks  the  status  of  all  of  the  valuators  that  provide 
input  to  the  FOG-M  simulator,  and  performs  scaling,  units 
conversion,  and  immediate  processing,  as  appropriate.  It 
determines  whether  to  accept  or  reject  a  "designate"  command, 
based  on  the  color  index  of  the  pixel  at  the  center  of  the  screen.  (If 
a  tank  is  in  the  crosshairs,  the  color  index  will  be  from  the  tank's 
color  ramp,  and  a  designate  command  will  be  accepted.  Otherwise, 
a  designate  command  will  be  ignored.) 

READDATA.C 

Input:  None. 

Output:  None. 

Side  Effects:      Readdata  fills  the  global  array  gridpixel. 

Description:  Readdata  opens  and  reads  the  values  from  the  terrain  elevation 
data  file  and  stores  the  values  in  the  gridpixel  array.  Note  that  the 
elevation  data  file  is  arranged  in  a  format  as  discussed  in  Chapter 
III.  The  gridpixel  array  is  arranged  in  straight  rows  and  columns 
analogous  to  the  geographic  positions  of  the  data. 


ROAD    BOUNDS. C 

Input:  Road  bounds  takes  as  input  the  following: 

-  Three  arrays  (ptl,  pt2  and  pt3)  containing  the  X  and  Z 
coordinates  of  three  points  along  the  centerline  of  the  road.  The 
line  segment  from  ptl  to  pt2  defines  the  first  segment  of  the  road. 
The  segment  from  pt2  to  pt3  defines  the  next  segment  of  the  road. 

-  A  float,  width,  which  is  the  width  of  the  road  in  feet. 

Output:  Road  bounds    returns    the    following    as    outputs:     -    Four    arrays 

(left  ptl,  right  ptl,  left  pt2,  and  right  pt2)  which  contain  the  X 
and  Z  coordinates  of  the  first  segment's  left  and  right  sides.  The 
left  side  runs  from  left  ptl  to  left  pt2  and  the  right  side  runs  from 
right  ptl  to  right  pt2. 

-  Four  integers,  first  xgrid,  first  zgrid,  last  xgrid  and  last  zgrid, 
which  are  the  indices  of  the  bounding  box  surrounding  the  first 
road  segment  (see  Figure  8.2). 

Side  Effects:      None. 

Description:  Given  three  points  along  the  center  line  of  the  road,  and  the  road's 
width,  road  bounds  computes  the  start  and  end  coordinates  for  the 
first  segment's  left  and  right  sides.  The  end  coordinates  are 
computed  as  the  intersection  of  the  first  segment's  left   (or  right) 
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side  with  the  second  segment's  left  (or  right)  side.  This  insures 
that  adjoining  segments  will  meet  cleanly.  The  second  function  of 
road  bounds  is  to  compute  a  bounding  box  around  the  first  road 
segment.  This  box  is  defined  as  the  row  indices  of  the  northern 
and  southern  most  gridsquares  that  the  road  segment  intersects, 
and  the  column  indices  of  the  eastern  and  western  most  gridsquares 
that  the  road  segment  intersects  (See  Chapter  VIII  for  a  more 
detailed  discussion). 


SORT   ARRAY.C 

Input: 


Output: 

Side  Effects: 
Description: 


Sort   array  takes  as  inputs: 

-  An  array  of  points,  puts. 

-  An  integer  that  is  the  number  of  entries  in  the  puts  array. 

-  A  boolean,  which  is  TRUE  if  the  array  should  be  sorted  in 
descending  order,  FALSE  if  the  array  should  be  sorted  in  ascending 
order. 

-  The  index  number  of  the  coordinate  that  is  the  sort  key:  0  for  the 
X  coordinate,  1  for  the  Y  coordinate,  and  2  for  the  Z  coordinate. 

Sort  array  returns  the  array  puts  with  the  points  sorted  according 
to  the  input  parameters. 

None. 

Sort  array  performs  a  simple  "bubble-sort"  of  the  input  points 
according  to  the  input  parameters. 


UP    LOOK    POS.C 


Input: 


Output: 

Side  Effects: 
Description: 


Up  look  pos  takes  the  following  as  inputs: 

-  The  heading  of  the  missile  in  radians. 

-  The  pan  angle  of  the  camera  in  radians. 

-  The  tilt  angle  of  the  camera  in  radians. 

-  The  X,  F,  and  Z  coordinates  of  the  missile's  position. 

-  The  X,  Y,  and  Z  coordinates  of  the  locked-on  target  (if  any). 

-  A  boolean  which  is  TRUE  if  the  missile  is  locked-on  a  target, 
FALSE  otherwise. 

Up  look  pos  returns  as  outputs  the  X,  F,  and  Z  coordinates  of  the 
camera's  look-at  position. 

None. 

Up  look  position  computes  a  point  along  the  camera's  line  of 
sight.  If  the  missile  is  locked  on  a  target,  the  look-at  position  is  the 
locked-on  target's  position.     Otherwise  it   is  any  point  along  the 
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camera's  line  of  sight.    See  Chapter  VI  and  Figure  6.2  for  a  more 

detailed  discussion. 


UP    MSL   POSIT. C 


Input: 


Output: 


Side  Effects: 
Description: 


Up   msl  posit  takes  as  inputs: 

-  The  heading  of  the  missile  in  radians. 

-  The  speed  of  the  missile  in  knots. 

-  The  X,  Y,  and  Z  coordinates  of  the  missile's  position. 

-  The  A",   Y,  and  Z  coordinates  of  the  locked-on  target  (if  any). 

-  A  boolean  which  is  TRUE  if  the  missile  is  locked-on  a  target, 
FALSE  otherwise. 

Up   msl  posit  returns  as  outputs: 

-  The  new  heading  of  the  missile  in  radians,  if  it  was  changed  to 
track  a  locked-on  target. 

-  The  new  heading  of  the  missile  in  degrees  measured  in  the 
compass  convention. 

-  A  boolean  which  is  TRUE  if  the  missile  is  still  flying  (has  not  hit 
a  target),  and  FALSE  if  the  missile  has  hit  the  target. 

None. 

Up  msl  posit  calculates  a  new  missile  position  for  the  next  frame. 
The  new  position  is  either  based  on  the  commanded  direction, 
speed,  and  altitude  (when  the  missile  is  NOT  locked  onto  a  target), 
or  the  commanded  speed  and  the  direction  to  the  target  (if  the 
missile  is  locked  onto  a  target).  For  a  detailed  discussion  of  the 
routine,  see  Chapter  VI. 


VIEW    BOUNDS. C 

Input:  View   bounds  takes  as  inputs  the  X,    Y,  and  Z  coordinates  of  the 

missile's  position;  the  X,    K,  and   Z  coordinates  of  the  camera's 
look-at  position;  and  the  field  of  view  (zoom)  value. 

Output:  View   bounds  returns  as  outputs  the  row  indices  of  the  northern 

and    southern    most    gridsquares    to    be    drawn,    and    the    column 
indices  of  the  western  and  eastern  most  gridsquares  to  be  drawn. 

Side  Effects:      None. 

Description:  The  purpose  of  view  bounds  is  to  construct  a  bounding  box  around 
the  gridsquares  which  are  to  be  drawn.  The  box  is  constructed  by 
extending  the  line  of  sight  vector  down  until  it  intersects  the 
minimum  elevation  plane.  The  view  bounds  extends  20 
gridsquares  north,  south,  east,  and  west  of  this  intersection  point. 


126 


If  the  missile's  position  is  not  within  the  bounds,  the  bounds  are 
extended  to  include  the  missile's  position.  For  a  more  detailed 
discussion,  see  Chapter  VI  and  Figure  6.5 


127 


APPENDIX  B         SOURCE  LISTINGS 


BUILD    ROAD 


#include  "stdio.h" 
^include  "fogm.h" 
#include  "files.h" 
#include  "gl.h" 
#include  "math.h" 

#define  X  0 
#define  Y  1 
#define  Z        2 

#define  DIAGONAL         0 
#define  HORIZONTAL       1 
#define  VERTICAL         2 

#define  LOWER  0 

#define  UPPER  1 

build   road() 

{ 

extern  Object  road[99][99]; 

extern  short  gridpixel[100][l00j; 

FILE  *fp,  *fopen(); 

float  road   width;  /*  road  width  if  feet  */ 

int  num    pts;  /*  number  of  data  points 

for  the  road  seqment  */ 
int  segnum  =  0; 
char  temp(l00]; 
int  cnt,  i,  j; 

int  vertex   cnt,  num   duplicates; 
float  gnd    level(); 
float  elev; 

float  ptl|3|,  pt2[3],  pt3[3|; 

float  nw   corner[3],  ne  corner[3],  sw   corner(3J,  se  corner[3]; 
float  right_ptl(3],  right_pt2[3j; 
float  left_ptl[3],  left_pt2(3]; 

float  north   bound,  south    bound,  east   bound,  west   bound; 
float  delta   x,  delta  z; 
float  seg   dir; 

int  ne   flag,  nw    flag,  se   flag,  sw    flag; 
int  xgrid,  zgrid; 

int  first   xgrid,  last   xgrid,  first   zgrid,  last   zgrid; 
float  polyl[l0][3); 

frontburTer(TRUE); 

fp  =  fopen(ROAD   FILEA"); 
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while  (fscanf(fp,  "%e'\  fcroadwidth)  !=  EOF)  { 
fscanf(fp,  "%d",  &num_pts); 
fscanfjfp,  "%e  %e",  &ptl(X],  &ptl[Z]); 
fscanfjfp,  "%e  %e",  &pt2(X],  &pt2(Zj); 

delta_x  =  pt2[X]  -  ptl[X]; 
delta_z  =  pt2[Z)  -  ptl[Z); 
seg   dir  =  atan2(delta   z,  delta  x); 

left~ptl(X]  =  ptl[X]  +  (cos(seg"_dir  +  HALFPI)*road_width/2.0); 
rightptljX]  =  ptl[X]  +  (cos(seg_dir  -  HALFPI)*road   width/2.0); 
left_ptl[Z]  =  ptl[Z]  +  (sin(seg_dir  +  HALFPI)*road  width/2.0); 
rightptljZ)  =  ptl[Z]  +  (sin(seg_dir-  HALFPI)  *  road_width/2.0); 
for  (cnt  =  3;  cnt  <=  num   pts  +  1;  ++cnt)  { 
if  (cnt  <=  num   pts)  { 

fscanf(fp,  "%e  %e",  &ptS[X],  &pt3[Z]); 

} 
else  { 

ptS[X]  =  pt2[X]; 
pt3[Z)  =  pt2|Zj; 

} 

/*  print  new  road  segment  number  on  title  screen  */ 

segnum  +=  1; 

pushmatrix(); 

ortho2(0.0,  1023.0,  0.0,  767.0); 

viewport(0, 1023,0,767); 

sprintf(temp,  "Building  road  segment:  %d%" ,  segnum); 

color(BLUE); 

rectf(780.0,  20.0,  1010.0,  30.0); 

color(CYAN); 

cmov2i(780,  20); 

charstr(temp); 

popmatrix(); 

/*  determine  the  boundaries  of  this  road  segment  */ 

road   bounds(ptl,  pt2,  pt3,  road   width,  left   ptl,  right   ptl, 

left_pt2,  right   pt2,  &first   xgrid, 

&first_zgrid,  &last   xgrid,  &last   zgrid); 

for  (xgrid  =  first   xgrid;  xgrid  <=  last   xgrid;  ++xgrid){ 

for  (zgrid  =  firstzgrid;  zgrid  <=  last   zgrid;  ++zgrid){ 

neflag  =  F~ALSE; 

nwflag  =  FALSE; 

swflag  =  FALSE; 

seflag  =  FALSE; 

vertex   cnt  =  -1; 

east_bound  =  (float)(xgrid  +  1)  *  FT   100M; 

westbound  =  (float)(xgrid)  *  FT100M; 

northbound  =  (float)  (zgrid  +  1)  *  FT100M; 

southbound  =  (float)  (zgrid)  *  FT100M; 

sw_corner[X]  =  west   bound: 
sw_corner[Z]  =  south   bound; 
elev  =  gridpixellzgrid] [xgrid!  &  elev   mask; 
swcornerjY]  =  pow(elev,  ALTSCALE); 
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se  corner[X]  =  east   bound; 

se  corner[Z]  =  south   bound; 

elev  =  gridpixel[zgridj[xgrid  +  l]  &  elev   mask; 

se  corner[Y]  =  pow(elev,ALTSCALE); 

nw   corner(X)  =  west   bound; 

nw  corner[Zj  =  north   bound; 

elev  =  gridpixel[zgrid+l](xgrid]  &  elevmask; 

nw   cornerjY]  =  pow(elev,ALTSCALE); 

ne  cornerjX]  =  east   bound; 

ne   cornerjZ]  =  north    bound; 

elev  =  gridpixel|zgrid+l][xgrid+l]  &  elev   mask; 

ne  cornerjY]  =  pow(elev,  ALTSCALE); 


/ '*  determine  points  of  intersection  between  the  left  and 

right  sides  of  the  road  and  the  eastern  grid  boundary 
and  add  these  points  to  the  polygon  vertex  array  */ 

do   boundary(VERTICAL,  UPPER,  xgrid,  zgrid,  se   corner,  ne  corner, 
left   ptl,  left   pt2,  right   ptl,  right   pt2,  &se   flag, 
&ne   flag,  polyl,  &vertex   cnt); 

/*  determine  points  of  intersection  between  the  left  and 

right  sides  of  the  road  and  the  northern  grid  boundary 
and  insert  these  points  into  the  polygon  vertex  array  */ 

do_boundary(HORIZONTAL,  UPPER,  xgrid,  zgrid,  necorner, 

nw   corner,  left   ptl,  left   pt2,  right   ptl, 

right   pt2,  &ne   flag,  &nw   flag,  polyl,  &vertex   cnt); 

/*  determine  points  of  intersection  between  the  left  and 
right  sides  of  the  road  and  the  diagonal  and 
insert  these  pointsinto  the  polygon  vertex  array  */ 

do   boundary(DIAGONAL,  UPPER,  xgrid,  zgrid,  nw   corner,  se  corner, 

leftptl,  left   pt2,  right_ptl,  right_pt2,  &nw_flag, 

<fcse   flag,  polyl,  &vertex  cnt); 

/*  remove  duplicate  entries  from  the  polygon  array  */ 

num   duplicates  =  0; 

for  (i  =  1;  i  <=  vertex  cnt;  ++i)  { 

if  ((polyl[i][0]  ==  polyl[i-lj[0|)  && 
(polyl[i][2]  ==  polyl[i-l][2]j)  { 

for  (j  =  i;  j  <  vertex   cnt  -  num   duplicates;  ++j)  { 
polyl[j][0]  =  polyl[j+l]iOj" 
polyl[j][l]  =  polyl[j+l](l] 
polyl[j][2]  =  polyl[j+l][2j 

} 

num   duplicates  +=  1; 

} 
} 
vertex   cnt  -=  num   duplicates; 
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if  (vertex   cnt  >  0)  {    /*  add  polygon  to  gridobject  */ 
if  (road[zgrid]  [xgrid!  !=  0)  { 

editobj(road[zgrid|[xgrid]); 

} 
else  { 

road[zgrid])xgrid]  =  genobj(); 

makeobj(road[zgrid][xgrid]); 

} 

color(ROADGREY); 

polf(vertex_cnt  +1,  &polyl[0][0j); 

linewidth(3); 

poly(vertex   cnt  +  1,  &polyl[0][0]); 

closeobj(); 

} 

vertex   cnt  =  -1; 
ne   flag~  =  FALSE; 
nwflag  =  FALSE; 
sw'flag  =  FALSE; 
seflag  =  FALSE; 

/*  determine  points  of  intersection  between  the  left  and 

right  sides  of  the  road  and  the  southern  grid  boundary 
and  insert  these  points  into  the  polgon  vertex  array  */ 

do  boundary(HORIZONTAL,  LOWER,  xgrid,  zgrid,  sw  corner, 

se   corner,  left   ptl,  left   pt2,  right   ptl, 

right   pt2,  &sw    flag,  &se   flag,  polyl,  &vertex   cnt); 

/*  determine  points  of  intersection  between  the  left  and 
right  sides  of  the  road  and  the  diagonal  and 
add  these  points  to  the  polygon  vertex  array  */ 

do   boundary(DIAGONAL,  LOWER,  xgrid,  zgrid,  se   corner,  nw   corner, 
leftptl,  left_pt2,  rightptl,  right_pt2,  &se_flag, 
&nw   flag,  polyl,  &vertex   cnt); 

/*  determine  points  of  intersection  between  the  left  and 

right  sides  of  the  road  and  the  western  grid  bound 
and  add  these  points  to  the  polygon  vertex  array  */ 

do   boundary(VERTICAL,  LOWER,  xgrid,  zgrid,  nwcorner,  swcorner, 
left   ptl,  left   pt2,  right   ptl,  right    pt2,  &nw   flag, 
&sw   flag,  polyl,  &vertex   cnt); 

/*  remove  duplicate  entries  from  the  polygon  array  */ 

num   duplicates  =  0; 

for  (i  =  1;  i  <=  vertex  cnt;  +  +  i)  { 

if  ((polyl(i][0j  ==  polyl[i-l][0])  && 
(polyl(i][2)  ==  polyl[i-l][2]j)  { 

for  (j  =  i;  j  <  vertex   cnt  -  numduplicates;  ++j)  { 

polyl[j][0]  -  polyl[j  +  l][0]7 
polyl[j][l]  =  polyl[j  +  l][l]; 
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polyl[j]2]  =  polyl[j  +  l][2]; 

} 

num   duplicates  +=  1; 

} 

} 

vertex   cnt  -=  num   duplicates; 

if  (vertex   cnt  >  0)  {    /*  add  polygon  to  grid   object  */ 
if  (road(zgrid](xgrid)  !=  0)  { 

editobj(road[zgridi[xgrid]); 

} 
else  { 

road[zgrid](xgrid]  =  genobj(); 

makeobj(road[zgrid][xgrid]); 

} 
color(ROADGREY); 

polf(vertex_cnt  +1,  &polyl[0][0]); 

linewidth(3); 

poly(vertex   cnt  +  1,  &polyl[0][0]); 

closeobj(); 
} 
} 
} 

rightptljX]  =  right_pt2[X]; 
right_ptl!Z]  =  right_pt2[Z]; 
left_ptl|Xj  =  left_pt2[Xj; 
leftptl(Z)  =  left_pt2[Z]; 
ptl[X]  =  pt2(X]; 
ptljZ]  =  pt2[Z|; 
pt2[X]  =  ptS[X]; 
pt2[Z]' =  pt3[Z]; 


} 
fclose(fp); 

frontbunrer(FALSE); 
} 
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BUILDTERRAIN 

/*    buildterrain.c  -  this  function  builds  objects  representing  1km  grid  squares 
in  3-D,  with  each  grid  square  generating  4  objects,  identical  except  for 
order  of  drawing  / 

^include  "gl.h"  /*  get  the  graphics  defs  */ 

^include  "device. h"     /*  get  the  graphics  device  defs  */ 
^include  "fogm.h"        /*  default  constants  */ 

^include  "math.h"        /*  math  function  declarations     */ 

buildterrain() 

{ 

/*  array  of  data  points  to  build  the  terrain  */ 

extern  short  gridpixel(lOOi[lOO]; 

extern  float  savetriangle[99i[99]|2][3][3j; 

extern  long  gridcolor[99][99]; 

extern  Object  target[99][99]; 

extern  float  ground   plane[4][3]; 

extern  long  gnd   plane   color; 

float  gnd   planeht; 

Coord    trianglelj3][3j,  triangle2[3](3j;         /*  polygon  coordinates  */ 

short  xgrid,  zgrid;  /*  indexes  into  the  grid  object  array  */ 

short  endrow,  endcol;  /*  miscellaneous  indexes  etc    */ 

int  row,  col; 

float  ax,ay,az;     /*  interior  point  for  use  in  the  lightpoly  function  */ 

float  lx,ly,lz;     /*  position  of  light  source  in  lightpoly  function  */ 

/*  min  and  max  colormap  indexes  for  lighting  the  poly  */ 
long  colormin,  colormax; 

/*  color  index  to  use  returned  by  the  lightpoly  function  */ 
long  colortouse,  colorl,  color2; 

char  temp[50j;      /*  character  string  for  countdown  */ 

float  x,y; 

float  gammacorr; 

long    rampamax,  rampamin,  rampbmax,  rampbmin; 
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int    startrow,  startcol,  coordidx,  vertex; 


lx  =  500  *  FT100M;        /*  direction  of  light  source  */ 
ly  =  100000  *  FT100M; 
lz  =  ly; 

frontbuffer(TRUE);         /*  write  to  front  buffer  */ 

/*  compute  color  for  ground   plane  polygon  */ 
gndplaneht  =  pow((float)MIN,  ALTSCALE); 
ground_plane[0][0]  =  -NUMXGRIDS  *  FEETPERGRID; 
ground   plane[0)[l]  =  gnd   plane   ht; 
ground"plane[0][2]  =  NUMZGRfDS  *  FEETPERGRID; 

ground _plane[l][0]  =  2.0  *  NUMXGRIDS  *  FEETPERGRID; 

ground_plane[l][l]  =  gndplane   ht; 
ground"plane[l][2J  =  NUMZGRI~DS  *  FEETPERGRID; 

ground_planej2][0]  =  2.0  *  NUMXGRIDS  *  FEETPERGRID; 

ground    plane[2][l]  =  gnd   plane   ht; 

ground~plane|2][2]  =  -2.0~*  NUMZGRIDS  *  FEETPERGRID; 

ground   plane  [8] [0]  =  -NUMXGRIDS  *  FEETPERGRID; 

ground    plane[3][l]  =  gnd   plane   ht; 

ground~plane[3|[2]  =  -2.0~*  NUMZGRIDS  *  FEETPERGRID; 

lightorient(ground   plane,4,0.0,0.0,0.0,lx,ly,lz,256,461,  &gnd    plane   color); 

/*  compute  coordinates  and  colors  for  triangles  and  store  in  global 
variable  savetriangle  for  later  display  */ 

for  (col  =  0;  col  <  99;  ++col)  { 

/*  print  new  countdown  number  on  title  screen  */ 

pushmatrix(); 

ortho2(0.0,  1023.0,  0.0,  767.0); 

viewport  (0,1028,0,767); 

sprintf(temp,  "Countdown  to  launch:  %d%",  98  -  col); 

color(BLUE); 

rectf(780.0,  15.0,  1010.0,  30.0); 

color(CYAN); 

cmov2i(788,  20); 

charstr(temp); 

popmatrix(); 

for  (row  =  0;  row  <  99;  ++row)  { 

/*  choose  which  color  ramp  to  use  so  that  a  checker  board 

effect  is  acheived  */ 
if  ((row+col)%2){ 

colormin  =  256; 

colormax  =  461; 
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} 

else  { 

colormin  =  462; 
colormax  =  667; 

} 

/*  build  the  polygon  */ 

trianglel[0][2]  =  (float)row  *  (-41.01)  *  8.0; 
trianglel[0][0]  =  (float)col  *  41.01  *  8.0; 

trianglel[0][lj  =  pow((float)(gridpixel[row][col]&elev_mask) 
,  ALTSCALE); 

triangleljl][2]  =  (float)row  *  (-41.01)  *  8.0; 
trianglel[l][0]  =  (float)  (col+l)  *  41.01  *  8.0; 
trianglel[l][l]  =  pow((float)(gridpixel[rowj[col+l]&elev   mask) 
, ALTSCALE); 

trianglel|2][2]  =  (float) (row  +  l)  *  (-41.01)  *  8.0; 
trianglel|2][0j  =  (float)col  *  41.01  *  8.0; 

trianglel[2][lj  =  pow((float)(gridpixel[row  +  l][col]&elev   mask) 
,  ALTSCALE); 

/*  copy  common  vertex  values  for  opposing  triangle  of  grid  */ 
for  (vertex  =  1;  vertex  <  3;  ++vertex)  { 

triangle2[vertex][0]  =  trianglel  [vertex]  [0]; 
triangle2[vertex][l]  =  trianglel[vertex][lj; 
triangle2[vertex)[2]  =  trianglel  [vertex]  [2]; 
} 

/*  change  corner  coordinate  to  form  opposing  triangle  of  grid  */ 
triangle2[0][2j  =  (float)(row  +  l)  *  (-41.01)  *  8.0; 
triangle2[0][0j  =  (float)(col+l)  *  41.01  *  8.0; 

triangle2[0][l]  =  pow((float)(gridpixel[row+l][colH-lj&elev   mask) 
,  ALTSCALE)  ; 

/*  compute  an  interior  point  for  trianglel    */ 

ax  =  trianglel[0][0]  +  15.0; 

ay  =  -10.0; 

az  =  trianglel[0]]2]  -15.0; 

/*  light  and  orient  trianglel  */ 

lightorient (triangle  1,3, ax, ay, az,lx,ly,lz, colormin,  colormax,  &colorl); 

/*  compute  interior  point  for  triangle2    */ 

ax  =  triangle2[0][0]  -  15.0; 

ay  =  -10.0; 

az  =  triangle2[0][2]  +15.0; 

/*  compute  the  light  for  and  orient  triangle2  */ 

lightorient (triangle2, 3, ax, ay, az,lx,ly,lz, colormin, colormax,  &color2); 

/*  compute  average  color  for  the  square  */ 
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colortouse  =  (colorl  +  color2)  /  2; 


/*  save  this  triangles  color  and  orientation  */ 
for  (vertex  =  0;  vertex  <  3;  +  +  vertex) 

for  (coordidx  =  0;  coordidx  <  3;  ++coordidx)  { 
savetrianglejrow]  [colj  [0]  [vertex]  [coordidx]  = 

triangle  1  [vertex]  [coordidx] ; 
savetriangle[rowi  [col]  [l]  [vertex]  [coordidx]  = 
triangle2[vertex]  [coordidx]; 

} 

gridcolor[row][col]  =  colortouse; 


} 
} 

frontbuffer(FALSE); 
I 
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COLORRAMP 


/*    constructs  the  color  ramps  to  be  used  for  displaying  the  terrain. 
If  greyscale  is  true,  constructs  greyscale  ramps,  else  it 
constructs  green  ramps.         */ 


^include  "fogm.h" 


/*  fogm  constants  */ 


colorramp  (greyscale, init) 
int  greyscale,  init; 


{ 


int  1; 


/*  build  two  gamma  corrected  color  ramps  with  slightly  offset  colors  */ 
if  (greyscale)  { 

gammaramp(l. 5, 256, 205, 255, 255,255, 50,50, 50) 

gammarampjl.5,462,205,245,245,245,40,40,40) 

gammaramp(l.5,668,180,235,235,235,30,30,30) 

mapcolor(SKYBLUE,230, 230,230); 

mapcolor(ROADGREY,35,35,35); 


;    /*  even  terrain  ramp  */ 
;    /*  odd  terrain  ramp  */ 
;    /*  tank  ramp  */ 
/*  sky  color  */ 


} 
else  { 


} 


gammaramp(  1.5,256,205,0,255,0,0,50,0); 
gammarampjl. 5, 462, 205, 0,245,0, 0,40,0); 
gammaramp(1.5,668,180,255,165,55,75,55,0); 
mapcolor(SKYBLUE,200,200,255); 
mapcolor(ROADGREY,35,35,35); 


/*  even  terrain  ramp  */ 
/*  odd  terrain  ramp  */ 

/*  tank  ramp  */ 
/*  sky  color  */ 


if  (init)  { 

mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 
mapcolor 


(16,0,70,0); 

(17,0,80,0); 

(18,0,90,0); 

(19,0,100,0) 

(20,0,110,0) 

(21,0,120,0) 

(22,0,130,0) 

(23,0,140,0) 

(24,0,150,0) 

(25,0,165,0) 

(26,0,180,0) 

(27,0,190,0) 

(28,0,210,0) 

(29,0,225,0) 

(30,0,240,0) 

(31,0,255,0) 

(32,75,55,0) 

(33,95,60,0) 

(34,115,70,0); 

(35,125,76,0); 


/*  set  up  colors  for  contour  map  */ 
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mapcolor(36, 135, 83,0); 

mapcolor(37, 145,90,0) 

mapcolor(38, 155,97,0) 

mapcolor(39, 165, 105,0); 

mapcolor(40, 175, 110,0); 

mapcolor(41, 185,113,0); 

mapcolor(42, 190, 118,0); 

mapcolor(43, 200, 127,0); 

mapcolor(44,210,135,30); 

mapcolor(45,225,145,35) 

mapcolor(46, 240, 155,45) 

mapcolor(47,255,165,55) 

for  (i=64;    i<128;  i+  +  )  mapcolor(i,0,0,255); 

for  (i=128;  i<256;  i++)  mapcolor(i,255,0,0); 

mapcolor(851, 0,150,0);  /*  set  up  colors  for  instruction  box  */ 

mapcolor(852, 255, 165,55); 

mapcolor(853, 95,60,0); 

mapcolor(854, 0,0,0);  /*  color  for  indicator  box  background*/ 
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COMPASS 

/*    compute  the  compass  heading  in  degrees  of  the  input  direction.  */ 

^include  "fogm.h"  /*  fogm  constants      */ 

float  compass(direction) 
double  direction; 

{ 

float  compassdir; 

compassdir  =  RTOD  *  direction; 
if  (compassdir  <=  90.0) 

compassdir  =  90.0  -  compassdir; 
else 

compassdir  =  450.0  -  compassdir; 

return  (compassdir); 
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DISPLAY   TERRAIN 


/*    Compute  which  polygons  need  to  be  drawn  to  display  the  terrain  and 
output  them  in  an  order  such  that  the  polygons  farthest  from  the  viewer 
are  drawn  first  and  those  closest  are  drawn  last. 

Note:  Eventhough  this  seems  like  a  long  routine,  it  is  broken  into  8 
independent  cases  based  on  the  direction  the  camera  is  looking. 
If  you  understand  one  case  the  others  are  merely  mirror  images  of  the 
algorighm  for  other  octants.  */ 

^include  "fogm.h" 
#include  "math.h" 
#include  "gl.h" 

display   terrain(vx,  vy,  vz,  px,  py,  pz,  fovy, 
firstxgrid,  firstzgrid,  lastxgrid,  lastzgrid) 

Coord  vx,  vy,  vz,  px,  py,  pz; 

int     fovy; 

short  firstxgrid,  firstzgrid,  lastxgrid,  lastzgrid; 


{ 


extern  float  ground   plane(4][3]; 

extern  long  gnd   plane  color; 

extern  Object  road[99][99]; 

extern  Object  target [99]  [99]; 

extern  float  savetriangle[99][99][2][3][3|; 

extern  long  gridcolor[99][99]; 

double  lookdir; 

int  threshold,  count,  startx,  startz; 

short  xgrid,  zgrid; 

float  tanval; 

float  y; 

if  (TV)  viewport(0, 474,0, 474); 
else  viewport(0, 767, 0,767); 
pushmatrixf); 

color(SKYBLUE); 
clear(); 

ortho2(0. 0,1023.0, 0.0, 767.0);         /*  outline  the  screen  */ 
color(BLACK); 

recti(0,0,1023,767); 
popmatrix(); 

pushmatrix(); 

perspective(fovy ,  1 .0,0.0, 19500.0) ; 

Iookat(vx,vy,vz,px,py,pz,0.0); 
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/*  determine  the  direction  of  the  line  of  sight    */ 

lookdir  =  (double)atan2((float)(vz  -  pz),  (float)(-(vx  -  px))); 

if  (lookdir  <  0.0)  lookdir  +=  TWOPI; 

/*  lay  down  the  ground  plane  */ 
color(gnd    planecolor); 
polf(4,  groundplane); 

/*  put  the  grid  objects  through  the  geometry  engine  in  an  order 

based  on  the  lookdir.    */ 
if  (lookdir  >  SEVEN  QTRPI) 

{ 

/*  8th  OCTANT     */ 

threshold  =  (int)(tan(lookdir+HALFPI)  +  0.5); 

count  =  0; 

startx  =  lastxgrid; 

startz  =  firstzgrid; 

while  (startz  <  =  lastzgrid)  { 

zgrid  =  startz; 

xgrid  =  startx; 

while  ((xgrid  <=  lastxgrid)  &&  (zgrid  <=  lastzgrid))  { 

color(gridcolor(zgrid]  [xgrid]); 

polf(3,&savetriangle[zgrid][xgridj(0][0|[0]); 

polf(3,&savetriangle[zgrid][xgridj[l][0][0]); 

if  (road[zgrid][xgrid]  !=  0)  callobj(road[zgrid]|xgrid]); 
if  (targetjxgridj [zgrid]  !=  0)  callobj(target[xgrid][zgrid]); 
/*  check  if  tank  should  be  drawn  now  */ 

zgrid  +=  1; 
count  +=  1; 

if  (count  >=  threshold)  { 

xgrid  +=  1; 

count  =  0; 
} 

} 

startx  -=  1; 
count  =  0; 

if  (startx  <  firstxgrid)  { 
startx  =  firstxgrid; 
startz  +=  threshold; 
} 
} 
} 
else  if  ((lookdir  >  THREE  HAL  VESPI)  &&  (lookdir  <=  SEVENQTRPI)) 

{ 
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/*  7th  OCTANT     */ 

tanval  =  tan(lookdir+HALFPI); 

if  (tanval  ==  0.0) 

threshold  =  1000; 
else 

threshold  =  (int)((1.0/tanval)  +  0.5); 

count  =  0; 

startx  =  lastxgrid; 

startz  =  firstzgrid; 

while  (startx  >=  firstxgrid)  { 

zgrid  =  startz; 

xgrid  =  startx; 

while  ((xgrid  >=  firstxgrid)  &&  (zgrid  >=  firstzgrid))  { 

color(gridcolor[  zgrid]  [xgrid]); 

polf(  3,  &savetriangle[  zgrid]  [xgrid]  [0][0][0]); 

polf(3,&savetriangle[zgrid]  [xgrid]  [l][0][0]); 

if  (road[zgrid];xgrid]  !=  0)  callobj(road[zgrid][xgrid]); 

if  (target[xgrid][zgrid|  !=  0)  callobj(target[xgrid][zgridj); 

xgrid  -=  1; 
count  +=  1; 

if  (count  >=  threshold)  { 

zgrid  -=  1; 

count  =  0; 
} 
} 

startz  +=  1; 
count  =  0; 

if  (startz  >  lastzgrid)  { 

startz  =  lastzgrid; 

startx  -=  threshold; 

} 

} 

} 

else  if  ((lookdir  >  FIVE  QTR  PI)  &&  (lookdir  <=  THREE  HALVES   PI)) 

{ 

/*  6th  OCTANT     */ 

tanval  =  -tan(lookdir+HALFPI); 

if  (tanval  ==  0.0) 

threshold  =  1000; 
else 

threshold  =  (int)((l.0/tanval)  +  0.5); 

count  =  0; 

startx  =  firstxgrid; 

startz  =  firstzgrid; 

142 


while  (startx  <=  lastxgrid)  { 
zgrid  =  startz; 
xgrid  =  startx; 

while  ((xgrid  <=  lastxgrid)  &&  (zgrid  >=  firstzgrid))  { 

color(gridcolor[zgrid][xgridj); 

polf(3,&savetriangle|zgrid]|xgrid][0|[0][0]); 
polf(3,&savetriangle[zgrid]  [xgrid]  [l][0][0]); 

if  (road[zgrid][xgrid]  !=  0)  callobj(road[zgrid] [xgrid]); 
if  (targetjxgrid] [zgrid]  !=  0)  callobj(target(xgrid][zgrid]); 
xgrid  +=  1; 
count  +=  1; 

if  (count  >=  threshold)  { 
zgrid  -=  1; 
count  =  0; 

} 
} 

startz  +=  1; 
count  =  0; 

if  (startz  >  lastzgrid)  { 
startz  =  lastzgrid; 
startx  +=  threshold; 
} 
} 
} 
else  if  ((lookdir  >  PI)  &&  (lookdir  <=  FIVE  QTR   PI)) 

{ 

/*  5th  OCTANT     */ 

threshold  =  (int)(-tan(lookdir+HALFPI)  +  0.5); 

count  =  0; 

startx  =  firstxgrid; 

startz  =  firstzgrid; 

while  (startz  <=  lastzgrid)  { 

zgrid  =  startz; 

xgrid  =  startx; 

while  ((xgrid  >=  firstxgrid)  &&  (zgrid  <=  lastzgrid))  { 
color(gridcolor[zgrid]  [xgrid]); 
polf(3,&savetriangle[zgrid]|xgrid][0j[0][0]); 
polf(3,&savetriangle[zgrid][xgrid][l][0][0]); 

if  (roadjzgridj [xgrid]  !=  0)  callobj(road[zgrid][xgrid]); 
if  (targetjxgrid] [zgrid]  !=  0)  callobj(target[xgrid][zgridj); 
zgrid  +=  1; 
count  +=  1; 
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if  (count  >=  threshold)  { 

xgrid  -=  1; 

count  =  0; 
} 
} 

startx  +=  1; 
count  =  0; 

if  (startx  >  lastxgrid)  { 
startx  =  lastxgrid; 
startz  +=  threshold; 
} 
} 
} 
else  if  ((lookdir  >  THREE  QTR   PI)  &&  (lookdir  <=  PI)) 

{ 

/*  4th  OCTANT     */ 

threshold  =  (int)(tan(lookdir+HALFPI)  +  0.5); 

count  =  0; 

startx  =  firstxgrid; 

startz  =  lastzgrid; 

while  (startz  >=  firstzgrid)  { 

zgrid  =  startz; 

xgrid  =  startx; 

while  ((xgrid  >=  firstxgrid)  &&  (zgrid  >=  firstzgrid))  { 

color(gridcolorlzgridj  jxgridj); 

polf(  3,  &savetriangle!  zgrid]  [xgrid]  [0][0|[0]); 

polf(3,&savetriangle[zgrid][xgrid][l][0][0]); 

if  (road[zgrid][xgridj  !=  0)  callobj(road|zgrid|[xgrid]); 

if  (target|xgrid] [zgrid]  !=  0)  callobj(targetixgrid]  [zgrid 

zgrid  -=  1; 
count  +=  1; 

if  (count  >=  threshold)  { 
xgrid  -=  1; 
count  =  0; 
} 
} 

startx  +=  1; 
count  =  0; 

if  (startx  >  lastxgrid)  { 

startx  =  lastxgrid; 

startz  -=  threshold; 
} 
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} 

else  if  ((lookdir  >  HALFPI)  &&  (lookdir  <=  THREE  QTR  PI)) 

{ 

/*  3rd  OCTANT     */ 

tanval  =  tan(lookdir+HALFPI); 

if  (tanval  ==  0.0) 

threshold  =  1000; 
else 

threshold  =  (int)((1.0/tanval)  +  0.5); 

count  =  0; 

startx  =  firstxgrid; 

startz  =  lastzgrid; 

while  (startx  <=  lastxgrid)  { 

zgrid  =  startz; 

xgrid  =  startx; 

while  ((xgrid  <=  lastxgrid)  &&;  (zgrid  <=  lastzgrid))  { 

color(gridcolor  [zgrid]  [xgrid]); 

polf(  3,  &savetriangle[  zgrid]  [xgrid]  [0][0](0]); 

polf(3,&savetriangle[zgrid]|xgrid][l][0][0j); 

if  (road[zgrid][xgridj  !=  0)  callobj(road(zgrid][xgrid[); 
if  (targetixgrid] [zgrid]  !=  0)  callobj(target[xgrid]]zgrid]); 
xgrid  +=  1; 
count  +=  1; 

if  (count  >=  threshold)  { 

zgrid  +=  1; 

count  =  0; 
} 


startz  -—  1; 
count  =  0; 

if  (startz  <  firstzgrid)  { 
startz  =  firstzgrid; 
startx  +=  threshold; 

} 
} 
} 
else  if  ((lookdir  >  QTR   PI)  &&  (lookdir  <=  HALFPI)) 


{ 


/*  2nd  OCTANT     */ 

tanval  =  -(tan(lookdir+HALFPI)); 

if  (tanval  ==  0.0) 

threshold  =  1000; 
else 

threshold  =  (int)((1.0/tanval)  +  0.5); 
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count  =  0; 

startx  =  lastxgrid; 

startz  =  lastzgrid; 

while  (startx  >=  firstxgrid)  { 

zgrid  =  startz; 

xgrid  =  startx; 

while  ((zgrid  <=  lastzgrid)  &:&  (xgrid  >=  firstxgrid))  { 

color(gridcolor  [zgrid]  [xgrid]); 

polf(3,&savetriangle[zgrid][xgrid][0][0][0]); 

polf(3,&savetriangle[zgrid|[xgrid][l]|0](0]); 

if  (road[zgrid] [xgrid]  !=  0)  callobj(road[zgrid][xgrid]); 
if  (targetjxgrid] [zgrid]  !=  0)  callobj(target[xgrid][zgrid|); 
xgrid  -=  1; 
count  +=  1; 

if  (count  >=  threshold)  { 

zgrid  +=  1; 

count  =  0; 
} 
} 

startz  -=  1; 
count  =  0; 

if  (startz  <  firstzgrid)  { 
startz  =  firstzgrid; 
startx  -=  threshold; 
} 
} 
} 
else  if  ((lookdir  >  =  0.0)  &&  (lookdir  <=  QTR  PI)) 

{ 

/*  1st  OCTANT     */ 

threshold  =  (int)(-tan(lookdir+HALFPl)  +  0.5); 

count  =  0; 

startx  =  lastxgrid; 

startz  =  lastzgrid; 

while  (startz  >=  firstzgrid)  { 

zgrid  =  startz; 

xgrid  =  startx; 

while  ((xgrid  <=  lastxgrid)  &&  (zgrid  >=  firstzgrid))  { 

color  (gridcolor[  zgrid]  [xgrid]); 
polf(3,&savetriangle[zgrid]  [xgrid]  [0][0][0]); 
polf(3,&savetrianglejzgrid]  [xgrid]  [l][0][0]); 

if  (road[zgrid| [xgrid]  !=  0)  callobj(road[zgridi[xgrid]); 
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if  (target[xgrid)[zgrid]  !=  0)  callobj(target(xgrid][zgridj); 
zgrid  -=  1; 
count  +=  1; 

if  (count  >=  threshold)  { 
xgrid  +=  1; 
count  =  0; 

} 
} 

startx  -=  1; 
count  =  0; 


if  (startx  <  firstxgrid)  { 
startx  =  firstxgrid; 
startz  -=  threshold; 

} 

} 
} 
popmatrix(); 

} 
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DIST   TO   LOS 


#include  "gl.h" 

^include  "math.h" 

float  dist   to   los(vx,vy,vz,px,py,pz, point) 

/*  compute  the  distance  from  the  point  "point"  to  the  line  of  sight  */ 

Coord  vx,vy,vz,px,py,pz; 
float  point[3]; 


{ 


float  a,b,c;    /*  direction  numbers  of  line  of  sight  */ 
float  d,e,f; 
float  dist; 

a  =  (float)(px  -  vx); 
b  =  (float) (py  -  vy); 
c  =  (float)(pz  -  vz); 

d  =  point[0]  -  (float)vx; 
e  =  point[lj  -  (float)vy; 
f  =  point[2]  -  (float)vz; 

dist  =  sqrt((up  i(e*c  -  f*b,2)  +  up _i(f*a  -  d*c,2)  +  up_i(d*b  -  e*a,2))/ 
(up_i(a,2)  +  up_i(b,2)  +  up_i(c,2))); 

return(dist); 
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DO    BOUNDARY 


#include  "gl.h" 
#include  "math.h" 
#include  "stdio.h" 
^include  "fogm.h" 

#define  X  0 
#define  Y  1 
#define  Z     2 

#define  DIAGONAL     0 
#define  HORIZONTAL  1 
#define  VERTICAL     2 

#define  LOWER        0 
#define  UPPER         1 

#define  NONE  0 

#define  INTERSECT    1 
#define  PROPER       2 


do   boundary(bound   type,  which   triangle,  xgrid,  zgrid, 
bound   start,  bound   end,  left   start, 
left   end,  right   start,  right   end,  start   corner   flag, 
end   corner   flag,  polyl,  vertex   cnt) 

int  bound   type,  which   triangle,  xgrid.  zgrid; 

float  bound   start|3],  bound   end[3],  left   start[3j,  left   end[3], 
right   start[3],  right   end[3]; 

int  *start   corner  flag,  *end   corner 

float  polyl(l0](3]; 

int  *vertex   cnt; 


{ 


int  test   index,  cnt,  index; 

float  bound_right[3j,  bound   left[3],  bound   start   edge[3], 
bound   end   edge[3]; 

float  vertex   array[l0][3]; 
float  road   poly[l0j[3]; 
float  grid_poly[l0][3]; 

int  intersect   cnt; 
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int  intersect   type,  decending   sort; 
float  upper   bound,  lower   bound; 

float  gnd_level(); 

int  in   this   poly(); 

intersect   cnt  =  -1; 

/*  compute  the  verticies  of  the  road  segment  currently 

being  worked  on  */ 
for  (index  =  0;  index  <  3;  ++index)  { 

road_poly[0] (index)  =  left   startfindex]; 

road   poly jl] [index)  =  left   end[index); 

road_poly[2][indexj  =  right   end[index); 

road_poly[3l [index]  =  right   start[index); 
} 

/*  compute  the  verticies  of  the  grid  triangle  associated  with 

this  boundary  */ 
grid_poly[0][X]  =  (float)(xgrid*FT_100M); 
gridj>oly[0][Z]  =  (float)((zgrid+l)*FT_100M); 
grid_poly[l][X]  =  (float)((xgrid+l)*FT_100M); 
grid    poly[l][Z]  =  (float) (zgrid*FT_100M); 
if  (whichtriangle  ==  UPPER)  {  " 

gnd_poly[2)(X]  =  (float)((xgrid+l)*FT_100M); 

grid_poly[2|iZ]  =  (float)((zgrid+l)*FT   100M); 

} 
else  { 

grid_poly[2)[X]  =  (float)(xgrid*FT_100M); 

grid_poly[2][Z]  =  (float)(zgrid*FT_100M); 

} 

if  (boundtype  ==  HORIZONTAL)  { 
test   index  =  X; 

} 

else  if  (boundtype  ==  VERTICAL)  { 
test   index  =  Z; 

} 

else  if  (boundtype  ==  DIAGONAL)  { 

test   index  =  Z; 
} 

if  (bound   start  [test   index]  <  bound   endjtest   index!)  { 
lower   bound  =  bound   startitest   index); 
upper   bound  =  bound   end[test   index); 

} 
else  { 

lower   bound  =  bound   end|test   index); 

upper   bound  =  bound   startjtest   index); 
} 
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/*  determine  points  of  intersection  between  left  and  right  sides 
of  the  road  and  the  boundary  */ 

line   intersect2(bound   start,  boundend,  right   start,  rightend, 
bound   right,  ^intersect   type); 
if  (intersecttype  ==  PROPER)  { 

/*  intersection  lies  on  road  line  segment,  add  intersection 

to  array  */ 
intersect   cnt  +=  1; 

vertex_array[intersect_cnt][X]  =  boundright(X); 
vertex   arrayjintersect   cnt][Z]  =  bound   rightjZj; 
vertexarrayjintersectcntjjY]  =  gnd_level(bound_right[X], 
-boundrightjZ]); 

} 

else  if  ((intersecttype  ==  INTERSECT)  <fc& 

(in   this   poly(grid   poly,  3,  right   start))  && 

(bound   rightjtest   index]  >  lower   bound)  && 

(bound   rightjtest   index]  <  upper   bound))  { 

/*  intersection  point  is  beyond  the  bound  of  the  road's  right 

line  segment,  but  the  right  start  point  is  inside  the  polygon  so 
add  the  road's  right  start  point  to  the  vertex  array  */ 

intersect   cnt  +=  1; 

vertex   arrayjintersect   cnt]|X]  =  right   startjX]; 

vertex   arrayjintersect   cnt]|Z]  =  right   start[Zj; 

vertex   arrayjintersect   cnt][Y]  =  gnd   level(right   startjX], 

-right   start[Zj); 

} 

else  if  ((intersect   type  ==  INTERSECT)  && 

(in   this_poly(grid   poly,  3,  right   end))  && 

(bound   rightjtest   index]  >  lower   bound)  && 

(bound   rightjtest   index]  <  upper   bound))  { 

/*  intersection  point  is  beyond  the  bound  of  the  road's  right 

line  segment,  but  the  right  end  point  is  inside  the  polygon  so 
add  the  road's  right  end  point  to  the  vertex  array  */ 

intersect   cnt  +=  1; 

vertexarrayjintersectcntjjX]  =  right   endjXj; 
vertexarrayjintersectcntjjZ]  =  right   endjZ); 
vertexarrayjintersectcntjjY]  =  gnd   level(right   endjX], 
-right   end[Z|); 

} 

line   intersect2(bound_start,  bound   end,  left   start,  left   end, 

bound   left,  ^intersect   type); 

if  (intersecttype  ==  PROPER)  { 

/*  intersection  lies  on  road  line  segment,  add  intersection 
to  array  */ 

intersect   cnt  +=  1; 

vertexarrayjintersect   cnt][X]  =  bound   leftjX]; 
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vertex   array  [intersect   cnt][Z]  =  bound   left[Z]; 

vertex   array  [intersect   cnt][Y]  =  gnd   level(bound   left[X], 

-bound   left[Z[); 

} 

else  if  ((intersectjype  ==  INTERSECT)  && 

(in   this   poly(grid   poly,  3,  leftstart))  && 

(bound   left[test   index]  >  lower  bound)  && 

(bound   left  [test   index]  <  upperbound))  { 

/*  intersection  point  is  beyond  the  bound  of  the  road's  left 

line  segment,  but  the  left  start  point  is  inside  the  polygon  so 
add  the  road's  left  start  point  to  the  vertex  array  */ 

intersect   cnt  +=  1; 

vertex   arrayjintersect   cnt][X]  =  left   startjX]; 

vertex   array[intersect   cnt][Z]  =  left   startjZ]; 

vertex   array[intersect   cnt][Y]  =  gnd   level(left   startjX], 

-left_start[Z]); 

} 

else  if  ((intersecttype  ==  INTERSECT)  && 

(in   this   poly(grid   poly,  3,  left   end))  && 

(bound   left[test   index]  >  lower   bound)  && 

(bound   leftftest   index]  <  upper   bound))  { 

/*  intersection  point  is  beyond  the  bound  of  the  road's  left 

line  segment,  but  the  left  end  point  is  inside  the  polygon  so 
add  the  road's  left  end  point  to  the  vertex  array  */ 

intersect   cnt  +=  1; 

vertex   array  [intersect   cnt][X]  =  left   end[X]; 
vertex   arrayjintersect   cnt][Z]  =  left   end[Z|; 
vertex   arrayjintersect   cnt][Y]  =  gnd   level(left   end[X], 
-left_end[Z]); 
} 

/*  if  either  of  the  bound's  end  points  fall  within  the  bounds  of  the 

road,  add  them  to  the  array*/ 
if  ((!*start   corner   flag)  &&  (in_this_poly(road    poly,  4,  bound   start)))  { 

/*  put  in  start  bound  point  */ 

*start   corner   flag  =  TRUE; 

intersect_cnt  +=  1; 

vertex   array  [intersect   cntj[X)  =  bound   start[X]; 

vertex   array|intersect   cnt][Z]  =  bound   startjZ]; 

vertex   arrayjintersect   cnt][Yj  =  bound   start[Y]; 

} 

if  ((!*end   corner   flag)  &&  (in   this   poly(road   poly,  4,  bound   end)))  { 

/*  put  in  end  bound  point  */ 

*end   corner   flag  =  TRUE; 

intersect   cnt  +  =  1; 

vertex   arrayjintersect   cnt][X]  =  bound   end[X]; 

vertex   arrayjintersect   cntjjZ]  =  bound   end[Z|; 

vertex   array[intersect   cnt][Y]  =  bound   endjY]; 
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} 

/*  determine  the  point  of  intersection  between  the  start  and  end 

bound  of  the  road  and  the  grid  boundary  */ 
line   intersect2(bound   start,  bound   end,  left   start,  right   start, 
bound   start   edge,  ^intersect   type); 
if  (intersect  Jype  ==  PROPER)  { 

/*  intersection  lies  on  road  line  segment,  add  intersection 
to  array  */ 

intersect   cnt  +=  1; 

vertex   array  [intersect   cnt][X]  =  bound   start   edge[X); 

vertex   array  [intersect   cntj[Z]  =  bound   start   edge[Z[; 

vertex   array  [intersect   cnt][Y]  =  gnd   level(bound   start   edge[X], 

-bound   start   edge[Z|); 

} 

line   intersect2(bound   start,  bound   end,  left   end,  right   end, 

bound   end    edge,  ^intersect    type); 

if  (intersect"  type  ==  PROPER)  { 

/*  intersection  lies  on  road  line  segment,  add  intersection 
to  array  */ 

intersect   cnt  +=  1; 

vertex   array  [intersect   cnt][X]  =  bound   end   edge[X]; 

vertex   arrayjintersect   cnt][Z]  =  bound   end   edge(Z); 

vertex   arrayjintersect   cntj[Y]  =  gnd   level(bound   end   edge[X], 

-bound   end   edge[Z]); 

} 

/*  put  the  points  from  the  vertex   array  into  the  polyl  array  in 

the  proper  order  */ 
decending   sort  =  (bound   startjtest   index]  !=  lower   bound); 
sort    array(vertex   array,  intersect   cnt,  decending   sort,  test   index); 

for  (cnt  =  0;  cnt  <=  intersect   cnt;  ++cnt)  { 
*vertex   cnt  +=  1; 

polyl[*vertex  cnt][X]  =  vertex  array[cnt][X] 
polyl[*vertex_cnt][Y]  =  vertex  array[cnt][Y 
polylj*vertex  cnt][Z]  =  -vertex   array[cnt][Z 
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EDIT   INDBOX 


/*  update  the  control  settings  of  the  indicator  box  */ 
#include  "fogm.h" 
finclude  "gl.h" 

edit   indbox(indbox,  speedtag,  headingtag,  elevtag,  altmsltag, 
zoomtag,  tilttag,  pantag,  desigtag,  speed,  compassdir, 
vx,  vy,  vz,  pan,  tilt,  zoom,  designate) 

Object  indbox; 

Tag  speedtag,  headingtag,  elevtag,  altmsltag,  zoomtag,  tilttag,  pantag, 
desigtag; 

float  speed,  compassdir; 

Coord  vx,  vy,  vz; 

double  pan,  tilt; 

int  designate; 

int  zoom; 

{ 

char  chspeed[5],  chheading|5|,  chelev[5  ,  chaltmsl[5]; 

float  gndlevelf); 

float  zoomtic,  pantic,  tilttic; 

sprintf(chspeed,"%4. Of", speed);  /*  convert  speed  to  string    */ 

sprintf(chheading,"%3. Of, compassdir);         /*  convert  heading  to  str     */ 
sprintf(chelev,"%4.0f",vy  -  gnd_level(vx,vz));    /*  convert  elev  AGL  to  str  */ 
sprintf(chaltmsl,"%4.0f\vy);  /*  convert  alt  MSL  to  str    */ 

/*  compute  new  location  for  zoom,  pan,  and  tilt  indicators  */ 

zoomtic  =  zoom  *     -0.2766    -  222.128; 
tilttic  =  tilt  *    721.92682  +  365.0; 
pantic    =  pan    *  -721.92682  +  435.0; 

editobj(indbox);  /*  update  the  indicator  display  */ 

objreplace(speedtag); 

charstr(chspeed); 

objreplace( headingtag); 

charstr(chheading); 

objreplace(  elev  tag); 

charstr(chelev); 

objreplace(  altmsltag); 

charstr(chaltmsl); 

objreplace(  zoom  tag); 

move2(  28.0,  zoomtic); 

objreplace(  tilttag); 
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move2(42.0,tilttic); 

objreplace(pantag); 

move2(pantic,27.0); 

objreplace(desigtag); 

cmov2i(designate  ?  10  :  19,10); 

charstr(designate  ?  "DESIGNATE"  :  "REJECT"); 

closeobj(); 
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EDIT   NAVBOX 


#include  "fogm.h" 
#include  "math.h" 
#include  "gl.h" 

edit   navbox(navbox,  arrowtag,  vx,  vz,  direction, firstxgrid,  firstzgrid, 

lastxgrid,  lastzgrid) 

Object  navbox; 

Tag  arrowtag; 

Coord  vx,  vz; 

double  direction; 

short  firstxgrid,  firstzgrid,  lastxgrid,  lastzgrid; 

{ 

Coord  arrowx,  arrowy,  larrowx,  larrowy,  rarrowx,  rarrowy; 

/*  compute  coordinates  of  arrow  line  segments  for  nav  control  box  */ 

arrowx  =  vx  +  cos(direction)  *  2.0  *  FEETPERGRID; 

arrowy  =  vz  -  sin(direction)  *  2.0  *  FEETPERGRID; 

larrowx  =  arrowx  +  cos(direction  -  2.3561945)  *  FEETPERGRID; 

larrowy  =  arrowy  -  sin(direction  -  2.3561945)  *  FEETPERGRID; 

rarrowx  =  arrowx  +  cos(direction  +  2.3561954)  *  FEETPERGRID; 

rarrowy  =  arrowy  -  sin(direction  +  2.3561945)  *  FEETPERGRID; 

/*  update  the  contour  map  display  with  new  info  */ 

editobj(navbox); 

objreplace(  arrowtag); 

move2(vx,vz); 

draw2(arrowx,  arrowy); 

draw2(larrowx,  larrowy); 

move2(arrowx,  arrowy); 

draw2(rarrowx,  rarrowy); 

rect(firstxgrid*FT_100M,-firstzgrid*FT_100M, 

(lastxgrid  +  1)*FT_100M,  (-lastzgrid-l)*FT_100M); 

closeobj(); 
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EXPLOSION 


#include  "gl.h" 
explosion() 

{• 

int  i,j; 


pushviewport(); 
viewport(0, 1023,0,767); 
color(BLACK); 
clearQ; 
swapbuffers(); 
color(RED); 
clear(); 
swapbuffersf); 
swapbuffers(); 
color(YELLOW); 
clear(); 
swapbuffers(); 
swapbuffers(); 
color(RED); 
clear(); 

swapbuffers(); 
swapbuffers(); 
color(YELLOW); 
clear(); 

swapbuffers(); 
swapbuffers(); 
color(RED); 
clearf); 
swapbuffers(); 
swapbuffersf); 

for  (i  =  0;  i  <  100000;  i+  +  ) 
for(j  =  0;j  <  10;j++] 
popviewport(); 
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FOGM  (MAIN) 


/*  fogm.c  —    an  IRIS-2400  program    by  Doug  Smith  &  Dale  Streyle 

It  reads  in  a  10km  x  10km  section  of  a  terrain  map,  computes  a  lighting 
and  shading  model  for  the  terrain,  and  allows  overflight  */ 

^include  "gl.h"  /*  get  the  graphics  defs  */ 

^include  "device. h"  /*  get  the  graphics  device  defs      */ 

^include  "fogm.h"  /*  constants  */ 

#include  "math.h"  /*  math  function  declarations         */ 

^include  "get.h"  /*  monitor  type  include  file  */ 

#include  "stdio.h" 

^include  "sys/signal.h"       /*  used  for  screen  dump  utility       */ 
^include  <sys/types.h>        /*  contains  the  time  sturcture  tms  */ 
^include  <sys/times.h>        /*  for  time  calls  */ 

short  gridpixel[l00]|100j;  /*  DMA  elevation  and  vegatation  data         */ 

float  savetriangle[99] [99] [2j [3] [3]; 
long  gridcolorj99|[99]; 
Object  road[99j[99]; 
Object  target(99](99); 

float  ground   plane[4][3]; 

long  gnd    plane   color; 

float  tgt  jk>s|MAX_TGTS][3]; 

short  tgt_grid_idx[MAX_TGTS][2j; 

short  tgt   dirMAX   TGTS],  tgt   total  =  0; 

float  randx,  randy,  randz;  /*  random  offsets  from  tank  reference  point  */ 

int  framecnt; 

float  min   elev,  max   elev; 

Coord  tankx,  tanky,  tankz; 

float  frames   sec[l000ll2l; 


main() 
{ 


int  greyscale  =  FALSE;     /*  FALSE  =  color,  TRUE  =  greys    */ 

int  designate;  /*  boolean  indicating  desig/reject  status  */ 

int  flying  =  TRLTE;  /*  boolean  controlling  flying  loop  */ 

int  active  =  TRUE;  /*  boolean  controlling  main  program  loop 

int  nbyte,  socket,  connect   client();  /*  networking  variables  &  subroutine  */ 
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struct  tms  timestruct;     /*  structure  for  real-time  clock  calls  */ 

int  tgt   idx;  /*  index  of  designated  target  */ 

double  direction;  /*  direction  of  travel  in  radians  */ 

float  speed;  /*  speed  of  travel  in  knots  */ 

float  compassdir;  /*  desired  direction  of  travel  in  compass  deg       */ 

int  fovy  =  550;  /*  field  of  view  in  perspective  command  */ 

double  pan  =  0.0, 

tilt  =  -15.0  *  DTOR;    /*  pan  and  tilt  angles  */ 

/*  contour  map,  indicator,  instruction  */ 
Object  contour,  navbox,  indbox,  instrbox; 
Object  tank,  pre   1   obj'7]; 

Tag    headingtag,  elevtag,  speedtag,  zoomtag,  arrowtag,  tilttag,  pantag; 
Tag    desigtag,  altmsltag.  pre   1   tag[6j; 

Colorindex  unmask; 

Coord  vx,  vy,  vz;  /*    viewer  x  y  and  z  coordinates  */ 

Coord  px,  py,  pz;  /*  reference  x  y  z  coordinates  for  lookat  */ 

Coord  tgtx,  tgty,  tgtz;  /*  targeted  position  on  tank  */ 

float  randseed();  /*  random  number  generator  initialization  */ 

int  frames  =  -1; 

long  seconds,  lastseconds,  totalseconds  =  0; 

int  numpolys; 

float  elapsed; 

int  idx; 

FILE  *fopen(),  *fp; 

/*  first  and  last  x  and  z  indexes  of  the  grid  objects  to  draw  */ 
short  firstxgrid,  firstzgrid,  lastxgrid,  lastzgrid; 

readdataf);    /*  read  the  data  file  into  the  gridpixel  array  */ 

/*  get  socket  number  for  networking  */ 

/*if  (NETWORKING)  socket  =  connect  _client("npscs-irisl",3);  */ 

init   iris();  /*  initialize  the  iris  */ 

unmask  =  (l<<getplanes())  -  1; 
writemask  (unmask); 

randseed(times(&timestruct));       /*  seed  the  random  §  generator  */ 
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init   tgts();  /*  define  targets  */ 

ScreenDump(SCREENDUMP);  /*  enable  screen  dumping  */ 

billboard();  /*  produce  intro  screen    */ 

colorramp(greyscale,TRUE);         /*  build  all  color  ramps  */ 

makescreens(pre   1   obj,  pre   1   tag);     /*  build  objects  for  prelaunch  */ 
makemap(&contour);  /*  build  map  object  */ 

pre   l_obj[CONTOUR]  =  contour; 

prelaunch(&vx,  &vy,  &vz,  ^direction,  &compassdir, 
&active,  prelobj,  preltag); 

if  (active)  { 

maketank(&tank);  /*  build  object  for  a  tank  */ 

build   road();       /*  build  the  objects  that  comprise  the  roads  */ 

/*  process  terrain  data  to  build  polygons  and  compute  lighting  */ 
buildterrain(); 

/*  build  object  for  the  navigation  display  contour  map  */ 
drawnavbox(&navbox,  &arrowtag); 

/*  build  an  object  for  the  indicator  box  */ 

makeindbox(&indbox,&  head  ingtag,&elevtag,&altmsltag,&speed  tag, 
&zoomtag,&tilttag,&pantag,&desigtag); 

makeinstrbox(&instrbox);     /*  build  object  for  control  instruction  box  */ 
}     /*  end  of  if  (active)  block  */ 
while  (active)  { 

framecnt  =  0; 

/*  initialize  the  operator  controls  (mouse  and  dials)  */ 

init   controls(&pan,  &tilt,  &fovy,  vy,  greyscale,  compassdir); 

pushviewport(); 

viewport(0, 1023, 0,767); 

color(SKYBLUE); 

clear(); 

popviewport(); 

callobj(instrbox); 

callobj(indbox); 

editobj(contour); 

objreplace(STARTTAG); 

viewport(768, 1023,512,767); 
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closeobj(); 

callobj(contour); 

swapbuffers(); 

callobj(instrbox); 

callobj(contour); 

editobj  (contour); 

objreplace(STARTTAG); 

viewport(0, 768, 0,768); 

closeobj(); 

flying  =  TRUE;  /*  missile  is  flying  */ 

designate  =  TRUE;      /*  a  target  can  be  designated  */ 

while(flying)    {  /*  until  tgt  is  hit  or  3-button  exit  */ 


/*  get  values  from  user  contols  (mouse  and  dials)  */ 
read   controls(&designate,  &greyscale,  &flying,  &active, 
&speed,  ^direction,  <fccompassdir,  &vy, 
&pan,  &tilt,  &fovy); 

/*  calculate  which  target  was  closest  to  the  line  of 

sight  */ 
if  (Idesignate)  { 

nearest   tgt(vx,vy,vz,px,py,pz,&tgt   idx); 
} 

/*  update  targets'  positions  */ 

get   tgt   posit(socket,  designate,  tgt   idx,  &tgtx,  &tgty,  &tgtz,  tank); 

/*  update  missile  position  */ 

update   missile   posit(&direction,  &compassdir,  speed, 

designate,  tgtx,  tgty,  tgtz, 

&vx,  &vy,  &vz,  &flying): 

/*  update  camera  lookat  position  */ 

update   look   posit(direction,  pan,  tilt,  vx,  vy,  vz, 

tgtx,  tgty,  tgtz,  designate,  &px,  &py,  &pz); 

/*  determine  which  polygons  need  to  be  drawn  */ 
view   bounds(vx,  vy,  vz,  px,  py,  pz,  tilt,  fovy, 
(kfirstxgrid,  &firstzgrid,  &lastxgrid,  &lastzgrid); 

/*  edit  control  display  objects  to  reflect  new  values  */ 

edit_navbox(navbox,  arrowtag,  vx,  vz,  direction,  firstxgrid, 

firstzgrid,  lastxgrid,  lastzgrid); 

edit   indbox(indbox,  speedtag,  headingtag,  elevtag,  altmsltag, 

zoomtag,  tilttag,  pantag,  desigtag,  speed, 

compassdir,  vx,  vy,  vz,  pan,  tilt,  fovy,  designate); 


/*  display  the  3-D  view  of  the  terrain  as  seen  by 
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the  camera         */ 
display   terrain(vx,  vy,  vz,  px,  py,  pz,  fovy, 
firstxgrid,  firstzgrid,  lastxgrid,  lastzgrid); 

/*  display  the  control  boxes  */ 
writemask(SAVEMAP); 
callobj(navbox); 
writemask(  unmask); 
callobj(indbox); 

swapbuffers(); 

seconds  =  times(&timestruct); 

numpolys  =  (lastxgrid  -  firstxgrid)*(lastzgrid-firstzgrid)*2; 

elapsed  =  (float) (seconds  -  lastseconds)/60.0; 

if  ((frames  >=  0)  &&  (frames  <  1000)  ){ 

frames   sec  [frames]  [0]  =  (float)numpolys; 

frames   sec  [frames]  [l]  =  1.0/elapsed; 

} 

totalseconds  +=  (seconds-lastseconds); 

if  (totalseconds  >  7200)  { 

compactify();     /*  do  garbage  collection  every  2  mins  */ 

totalseconds  =  0.0; 

} 

lastseconds  =  seconds; 

frames  +=  1; 

}     /*  end  of  flying  loop  */ 

if  (active)  {      /*  explode  &  restart  */ 

explosion(); 

prelaunch(&vx,  &vy,  &vz,  ^direction,  &compassdir, 

^active,  pre   1   obj,  pre   1   tag); 
} 

}  /*  end  of  active  loop  */ 

/*  write  out  performance  stats  */ 

fp  =  fopen("speed.data",  "w"); 

if  (frames  >  999)  frames  =  999; 

for  (idx  =  0;  idx  <=  frames;  ++idx)  { 

fprintf(fp,"%.2f  %.2f0,  frames_sec[idx][0],  frames_sec[idx][l]); 
} 
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/*  gracefully  exit  */ 
if  (NETWORKING)  close(socket); 
setmonitor(HZ60); 
color(BLACK); 
clear(); 
swapbuffers(); 
clearQ; 
gexit(); 
textinit(); 
exit(); 
/*  end  of  main  */ 
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FILES.H 


/*    These  are  the  files  which  contain  data  for  the  terrain  elevations 

and  roads     */ 
#define  TERRAIN  FILE  "/work/terrain/tenkmsq.dat" 
#define  ROAD   FILE  "/work/terrain/Road.data" 


FOGM.H 

^define        elev   mask  Oxlfff  /*  mask  to  obtain  elev  value  from  datum       */' 

#define  veg   mask         0x0007  /*  mask  to  obtain  vegatation  value  from 

shifted  datum  */ 
#define        RD  0  /*  code  for  reading  a  file  in  "open"  */ 

#define  MAX  2800         /*  max  elev  (ft)  in  contour  map  */ 

#define  MIN  967  /*  min  elev  (ft)  in  contour  map  */ 

#define  SKYBLUE      4095         /*  color  index  for  sky  color  */ 

#define  ROADGREY  850  /*  color  index  for  the  road  */ 

#define  DELTAFOVY  50  /*  field  of  view  (zoom)  increment  of  5  deg  */ 

#define  PI  3.1415927 

#defineTWOPI  6.2831853 

#define  HALFPI  1.5707963 

#define  THREE  HALVES   PI  4.7123889 

#define  QTR   PI  0.7853982 

#define  THREE  QTR  PI      2.3561945 

#define  FIVE  QTR   PI       3.9269908 

#define  SEVEN  QTR   PI      5.4977871 

#define  RTOD  57.29578    /*  radians  to  degrees  conversion  factor      */ 

#define  DTOR  0.0174533  /*  degrees  to  radians  conversion  factor      */ 

#define  FPSTOKTS         35.525148  /*  convert  feet  per  60th  seconds  to  knots    */ 
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#define  PANSENS       30.0         /*  scale  factors  (sensitivity)  for 

navigaion  controls  (mouse  and  dials)       */ 

#define  SPEEDSENS  20 

#define  TILTSENS      50.0 

#define  DIRSENS        20.0 

#define  MAXLOOKDIST    32808.0     /*  maximum  distance  that  the  camera  can 

look  ahead  in  feet  */ 

#define  FEETPERGRID     3280.8      /*  number  of  feet  in  1000  meters  */ 

^define  ALTSCALE    1.05         /*  altitude  expansion  factor,  altitudes  are 

raised  to  this  power  to  give  an 
exagerrated  effect  */ 

#define  NUMXGRIDS  10  /*  number  of  IK  grid  squares  in  the  East- 

West  direction  */ 

#define  NUMZGRIDS  10  /*  number  of  Ik  grid  squares  in  the  North- 

South  direction  */ 

#define  FT10K  32808       /*  number  FT  in  lOKm  */ 

#define  FT100M  328.08      /*  number  FT  in  100m  */ 

#define  GRID   FACTOR  13.03781    /*  conversion  factor  */ 

#define  TV  0  /*  0  for  SGI  monitor,  1  for  TV  */ 

#define  SCREENDUMP         1  /*  1  to  enable  screen  dumping,  0  otherwise    */ 

#define  NETWORKING         0  /*  1  for  target  networking,  0  otherwise       */ 

^define  INIT   PAN  0  /*  initial,  min  and  max  pan  angles  in  deg.  */ 

#define  MIN  _PAN  -25 

#define  MAXPAN  25 

#define  INITTILT  -15  /*  initial,  min  and  max  tilt  angles  in  deg.*/ 

#define  MIN  JTILT  -25 

#define  MAX  TILT  15 

#define  MAX   ALT  17000        /*  maximum  altitude  for  missle        */ 

#define  MINALT  0  /*  minimum  altitude  for  missle        */ 

#define  INITSPEED         200  /*  init,  min  and  max  spd  (kts)  for  missle  */ 

#define  MINSPEED  0 

#define  MAXSPEED  400 

#define  INITFOVY  550  /*  initial  field  of  view  in  tenth  degrees  */ 
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^define 

CONTOUR 

^define 

SCREEN1 

1 

#define 

SCREEN2 

2 

^define 

SCREEN3 

3 

#define 

INSTR 

4 

^define 

STATS 

5 

^define 

FLTPATH 

#define 

LAUNCH 

0 

^define 

TARGET 

1 

#define 

DIR 

2 

#define 

HEAD 

3 

^define 

TGT           4 

^define 

MISSILE 

5 

0  /*  Indicies  for  array  obj 


/*  Indicies  for  array  tag 


#denne  MAX  TGT  COLOR     847 
#define  MINTGT  COLOR     668 

#define        MAX  TGTS       100 

#define        SAVEMAP  OxOOCO 
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GAMMARAMP 

/*       This  routine  puts  a  gamma-corrected  color  ramp  into  the  color  map.        */ 

^include  <math.h> 

gammaramp(gammaconst,firstcolor,ncolors, 
brightred,brightgreen,  bright  blue, 
darkred,darkgreen,darkblue) 

float  gammaconst;     /*  Strength  of  Gamma  correction  (try  1.0)  */ 

long  firstcolor;       /*  index  number  of  the  first  color  to  set  */ 

long  ncolors;  /*  the  number  of  colors  to  set  */ 

long  brightred,brightgreen,brightblue;    /*  the  bright  end  of  the  ramp  */ 

long  darkred,darkgreen,darkblue;  /*  the  dark  end  of  the  ramp     */ 

{ 

long  i;     /*  temp  loop  index  */ 

float  scl;    /*  scale  factor  for  gamma  correction  */ 

long  gcred.gcgreen,gcblue;    /*  gamma  corrected  colors  */ 


for(i=0;  i  <  ncolors;  i  +  +  )  /*  for  all  colors...*/ 

{ 

/*  compute  the  scale  factor  */ 

scl  =  pow (( float )i/( float )( ncolors- 1)  ,  1.0/gammaconst); 

/*  compute  the  gamma  corrected  colors  */ 
gcred  =  scl  *  (brightred  -  darkred)  +  darkred; 
gcgreen  =  scl  *  (brightgreen  -  darkgreen)  +  darkgreen; 
gcblue  =  scl  *  (brightblue  -  darkblue)  +  darkblue; 

mapcolor(firstcolor+i,  gcred,  gcgreen,  gcblue);  /*  set  the  color  */ 
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GET   TGT   POS 


/*  get  targets'  positions  from  irisl  if  networking.  Otherwise  moves  10  targets 
in  straight  lines,  reversing  when  they  hit  an  edge  */ 

^include  "fogm.h" 

^include  "gl.h" 

#include  "math.h" 

^include  <sys/types.h>       /*  contains  the  time  sturcture  tms  */ 

^include  <sys/times.h>       /*  for  time  calls  */ 

get   tgt   posit(socket, designate, tgt   idx,tgtx,tgty,tgtz,tank) 

int  socket,  designate,  tgt   idx; 
float  *tgtx,  *tgty,  *tgtz; 
Object  tank; 
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extern  float  tgt_pos[MAX_TGTS][3]; 

extern  float  randx,  randy,  randz; 

extern  Object  target[99]j99]; 

extern  short  tgt   grid   idxjMAX   TGTS][2]; 

extern  short  tgttotal,  tgt_dir[MAX_TGTS]; 

short  i,  tgt   num; 

int  nbyte,  addl(); 

float  gnd    level(),  dir,  dx,  dz,  distance; 

long  dist,  d2; 

static  long  seconds; 

static  long  lastsec  =  -999;        /*  -999  is  flag  to  indicate  no  value  */ 

struct  tms  timestruct; 

seconds  =  times(&timestruct); 

if  (lastsec    ==  -999)     /*  compute  distance  targets  move  ahead  */ 

distance  =  0.0; 
else 

distance  =  (float)((15.0/FPS_TO_KTS)*(seconds  -  lastsec)); 

lastsec  =  seconds;  /*  save  for  next  pass  */ 

for  (i  =  0;  i  <  tgt   total;  i+  +  )       /*  delete  targets  from  old  positions  */ 
if  (target[tgt_grid_idx[i][0]][tgt_grid_idx[i][l]])  { 

delobj( target |tgt_grid_idx[i][0]] [tgt   grid   idx[i)[l]]); 
targetjtgt_grid_idx[iJ[0]][tgt_grid_idx[i][l]]  =  0; 
} 

if  (NETWORKING)  { 

nbyte  =  read(socket,  &tgt   total,  sizeof(tgt   total)); 
for  (i  =  0;  i  <  tgttotal;  i++)  { 

nbyte  =  read(socket,  &tgt   grid   idx[i][0],  sizeof(short)); 

nbyte  =  read(socket,  &tgt_grid_idx[i][l],  sizeof(short)); 
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nbyte  =  read(socket,  &tgt_pos(i][0],  sizeof(float)); 
nbyte  =  read(socket,  &tgt  pos[i][l],  sizeof(float)); 
nbyte  =  readfsocket,  &tgt  pos(i][2],  sizeof(float)); 
nbyte  =  read(socket,  &tgt_dir[i],  sizeof(short)); 

} 

} 
else  { 

tgttotal  =  10; 

for  (i  =  0;  i  <  tgttotal;  i++)  { 

dir  =  (float) (tgt_dir|i]  /  10)  *  DTOR; 
tgt   pos[i][0j  +=  cos(dir)  *  distance; 
tgt   pos[i][2]  -=  sin(dir)  *  distance; 
tgt2grid_idx[i][0]  =  (short)(tgt_pos[i][0]/FT_100M); 
tgt_grid_idx[i][l]  =  (short)(-tgt_pos[ij[2]/FT_100M); 
if  ((tgt_pos[i][0]  >  FT_10K)  ||  (tgt_pos[i][0]  <  0))  { 
if  (tgt_dir[i|  >  1800)  tgt_dir[i]  -=  1800; 
else  tgt_dir[ij  +=  1800; 
tgt_pos[i][l]  =  0.0; 

} 

else  if  ((tgt_pos[ij[2]  <  -FT_10K)  ||  (tgt_pos[i][2]  >  0))  { 

if  (tgt_dir[i|  >  1800)  tgt_dir[i]  -=  1800; 

else  tgt_dir!i]  +=  1800; 

tgt_pos[i][lj  =  0.0; 

} 

else  tgt   pos[i][l]  =  gnd   level(tgt   pos[i][0l,  tgt   pos[i][2]); 

} 
} 
if  (Idesignate)  { 

if  (NETWORKING)  {  /*  find  which  target  is  designated  */ 

dist  =  up_i((float)(tgtj)osjO][0]  -  *tgtx),2)  + 

up_i((float)(tgt_pos[0](2]  -  *tgtz),2); 
tgt   idx  =  0; 
for  (i  =  1;  i  <  tgttotal;  i+  +  )  { 

d2  =  up_i((float)(tgt_pos[i][0]  -  *tgtx),2)  + 

up   i((float)(tgt_pos(i)[2]  -  *tgtz),2); 
if  (d2  <  dist)  { 
dist  =  d2; 
tgt   idx  =  (int)i; 
} 
} 
} 

*tgtx  =  tgt  pos[tgt  idxjjO]  +  randx; 
*tgty  =  tgt  pos|tgt  idx][l]  +  randy; 
*tgtz  =  tgt_pos[tgt_idx][2]  +  randz; 

} 

tgtnum  =  tgt   total; 

for  (i  =  0;  i  <  tgt   num;  i+  +  )  { 

dx  =  tgt_pos[i][0]  -  (float)tgt_grid_idx[i][0]  *  FT100M; 
dz  =  (float)(-tgt_grid_idx[ij[l])  *  FT100M  -  tgt_pos[i][2]; 
if  (dx  <  15.0) 

if  (dz  <  15.0)  { 

addl(i,-l,0); 
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addl(i,-l,-l); 

addl(i,0,-l); 

} 

else  if  (dz  >  313.0)  { 

addl(i,0,l); 

addl(i,-l,l); 

addl(i,-l,0); 

} 

else  addl(i,-l,0); 

else  if  (dx  >  313.0) 
if  (dz  <  15.0)  { 

addl(i,0,-l); 

addl(i,l,-l); 

addl(i,l,0); 

} 

else  if  (dz  >  313.0)  { 

addl(i,l,0); 

addl(i,l,l); 

addl(i,0,l); 

} 

else  addl(i,l,0); 

else  if  (dz  <  15.0)  addl(i,0,-l); 

else  if  (dz  >  313.0)  addl(i,0,l); 

} 

for  (i  =  0;  i  <  tgt   total;  i+  +  )       /*  add  targets  to  new  positions  */ 
if  (target!tgt_grid_idx[i][0]][tgt_grid_idx[i][l]])  { 

editobj(target(tgt   grid   idx[i][0]][tgt   grid   idx[i](l]]); 

pushmatrix(); 

translate  ( t  gt  _posji|[0],  tgt  _pos[i][l],  tgt  _pos[i|  [2]); 

rotate(tgt_dir(i],  'Y'); 

callobj(tank); 

popmatrix(); 

closeobj(); 


\ 


{ 
targetjtgt   grid   idx[ij[0]][tgt   grid   idx[i][l]]  =  genobj(); 
makeobj(targetjtgt   grid   idxji] [0] ] [tgt   grid   idx[i][l]]); 
pushmatrix(); 

translate(tgt   pos[i][0],tgt   pos[i][l],tgt   pos[i][2J); 
rotate(tgt_dir[i),  'Y'); 
callobj(tank); 
popmatrix(); 
closeobj(); 


addl(tgt   num,x,z) 

short  tgt   num,x,z; 

{ 

extern  float  tgt_pos[MAX_TGTS][3]; 
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extern  short  tgt_grid_idx[MAX_TGTS][2]; 
extern  short  tgt   total,  tgt__dir|MAX_TGTS]; 
short  i; 


tgt   pos[tgt   total][0]  =  tgt   posjtgt_num][0];  /*  copy  pos.  for  "new"  tgt  */ 

tgt   posjtgt  totaljjl]  =  tgt   posjtgt   numj[l] 

tgt   posjtgt   total](2]  =  tgt   pos[tgt   num][2] 

tgt   dirjtgt   total]  =  tgt   dir[tgt   num];  /*  copy  dir  for  "new"  tgt  */ 

tgt   grid   idx[tgt   total](0]  =  tgt   grid   idx[tgt_num][0]  +  x;  /*  set  pos  in    */ 

tgt   grid   idxjtgt   total][l]  =  tgt   grid   idx[tgt_numj[l]  +  z;  /*  new  grid  sq  */ 

for  (i  —  0;  i  <  2;  i+  +  )  {        /*  reset  if  new  grid  sq  outside  10km  square  */ 

if  (tgt   grid   idxjtgt   total] [i]  <  0)  tgt   grid   idx(tgt   total] [i]  =  0; 

if  (tgt_grid_idxjtgt_total]jij  >  98)  tgt_grid_idx[tgt_total](i]  =  98; 

} 

tgt   total  +  +  ; 
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GND   LEVEL 


^include  "math.h" 
^include  "fogm.h" 
#define  X   0 
#define  Y    1 
#define  Z    2 
float  gnd   level(vx,  vz) 

float  vx,  vz; 


extern  short  gridpixel(lOO][lOO]; 

float  interp  elev(); 

float  grid   level(); 

float  point(3],  nw   corner{3],  ne   corner[3],  sw   corner[3],  se  corner[3]; 

float  intersect[3[; 

float  elev; 

int  xgrid,  zgrid,  intersect   type; 

/*  determine  which  triangle  the  point  falls  in  */ 

xgrid  =  (int)(vx/FT_100M); 

zgrid  =  (int)(-vz/FT_100M); 

if  (xgrid  <  0)  xgrid  =  0; 

if  (xgrid  >  98)  xgrid  =  98; 

if  (zgrid  <  0)  zgrid  =  0; 

if  (zgrid  >  98)  zgrid  =  98; 

point(X]  =  vx; 

point[Z]  =  -vz; 

nw   corneriX]  =  (float) (xgrid*FT_100M); 

nwcornerlZ]  =  (float)((zgrid  +  l)*FT_100M); 

elev  =  gridpixel[zgrid+l][xgrid]  &  elev   mask; 

nw   corner  Y]  =  pow(elev,  ALTSCALE); 

swJcorner[Xj  =  (float)  (xgrid*FT_100M); 

swcornerjZl  =  (float)  (zgrid*FT_100M); 

elev  =  gridpixel[zgrid) [xgrid]  &  elev   mask; 

sw   corner[Y]  =  pow(elev,  ALTSCALE); 

ne~corner[X)  =  (float)((xgrid  +  l)*FT_100M); 

ne_corner[Z]  =  (float)((zgrid+l)*FT_100M); 

elev  =  gridpixel(zgrid+l](xgrid+l]  &  elev   mask; 

ne   corner[Y]  =  pow(elev,  ALTSCALE); 

seJcorner[X]  =  (float)((xgrid+l)*FT_100M); 

se_corner[Z]  =  (float)(zgrid*FT   100M); 

elev  =  gridpixeljzgridj [xgrid  +  l)  &  elev   mask; 

se  cornerjYj  =  pow(elev,  ALTSCALE); 

if  (-vz  <  (nw   cornerjZj  -  (vx  -  nw   cornerfXj)))  { 
/*  point  is  in  the  lower  triangle  */ 

/*  find  the  point  of  intersection  of  a  line  through  vx,vz 
and  the  sw   corner  with  the  diagonal  */ 
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} 


line   intersect2(sw   corner,  point,  nw   corner,  se   corner,  intersect, 
^intersect   type); 

/*  find  the  elevation  of  the  intersection  on  the  diagonal  */ 
intersectjY]  =  interp  elev(nw   corner,  se   corner,  intersect); 

/*  find  the  elevation  of  the  point  vx,  vy  */ 
return(interp  elev(sw   corner,  intersect,  point)); 

} 
else  { 

/*  point  is  in  the  upper  triangle  */ 

/*  find  the  point  of  intersection  of  the  diagonal  with  a  line 

through  th  ne  corner  and  the  point  */ 
line   intersect2(ne   corner,  point,  nw   corner,  se   corner,  intersect, 
&intersect   type); 

/*  find  the  elevation  of  the  intersection  on  the  diagonal  */ 
intersectjY]  =  interp   elev(nw   corner,  se   corner,  intersect); 


} 


/*  find  the  elevation  of  the  point  vx,  vz  */ 
returnfinterp  elev(ne   corner,  intersect,  point)); 
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IN   THIS   POLY 


#include  "gl.h" 

#define  X  0 

#define  Y  1 

#define  Z  2 

#define  PROPER   2 


int  in   this   poly(polygon,  num   vertex,  point) 
float  polygon[l0][3]; 
int  num   vertex; 
float  point[3]; 


{ 


int  index; 

int  pt   in,  intersect   type; 

int  num   crossings; 

float  max   x,  max   z,  min   x,  min   z; 

float  intersect [3]; 

float  old   intersect[3]; 

float  start   test   line[3|; 

maxx  =  polygon[0](X]; 
min  x  =  polygon[0](X]; 
max  z  =  polygon(0)[Z]; 
min   z  =  polygon[0][Z]; 

for  (index  =  1;  index  <  num   vertex;  +  +  index)  { 

if  (polygon[index][X]  <  min   x)  min   x  =  polygon[index][X]; 

if  (polygon[indexj[X]  >  max   x)  max   x  =  polygonjindex][Xj; 

if  (polygon[index|jZ]  <  min   z)  min   z  =  polygon[index][Z|; 

if  (polygon[index][Z]  >  max   z)  max   z  =  polvgon[indexj[Z]; 
} 

if  ((pointjX]  <  max_x)  &&  (pointjX]  >  min_x)  &&  (pointjZj  <  max_z)  && 
(pointjZ]  >  minz))  { 

/*  point  may  be  polygon,  test  further  by  constructing  a  vertical  line 

from  the  point  to  a  point  outside  the  polygons  bounds.    Count  the  number 
of  times  this  line  crosses  a  side  of  the  polygon.    If  it  crosses  an 
odd  number  of  times  the  point  is  in  the  polygon,  otherwise  it  is 
outside  the  polygon  */ 

start   test   line[X]  =  point(X|; 

start   test   line[Z]  =  max   z  +  1000.0; 

num   crossings  =  0; 

old   intersect [X]  =  -999.0; 
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} 


old   intersectjZ]  =  -999.0; 

for  (index  =  0;  index  <  numvertex  -1;  +  ->-index)  { 

line   intersect2(start   test   line,  point,  &polygon[index][0j, 

&polygon[index+l][0],  intersect,  ^intersect   type); 

/*  if  a  proper  intersection  exists  and  it  is  not  the  same  point 

as  the  previous  intersection  (i.e  it  didn't  intersect  a  vertex), 
then  add  one  to  the  number  of  crossings  */ 
if  ((intersecttype  ==  PROPER)  &&  ((intersect(X]  !=  oldintersectjX]) 

|   (intersectjZ]  !=  old   intersectjZ])))  numcrossings  +  =  1; 
old   intersect[X]  =  intersect[X|; 
old   intersectjZ)  =  intersectjZ); 

} 

line_intersect2(start   test   line,  point,  &  polygon]  num   vertex- 1][0], 

&polygon(0][0),  intersect,  ^intersect   type); 

if  (intersect   type  ==  PROPER)  num   crossings  +=  1; 

/*  if  the  number  of  crossings  is  even,  the  point  was  outside  */ 
pt   in  =  ((num   crossings  %  2)  !=  0); 
return(pt   in); 

} 

else  { 

return(FALSE); 
} 
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INIT   CTRLS 


/*    initialize  the  operator  controls  */ 

^include  "fogm.h"  /*  fogm  constants  */ 

^include  "device. h"  /*  graphics  device  definitions  */ 

^include  "gl.h"  /*  graphics  routine  definitions  */ 
^include  "math.h"  /*  math  function  definitions     */ 

init   controls(pan,  tilt,  fovy,  alt,  greyscale,  compassdir) 

double  *pan;  /*  initial  pan  angle  in  radians  */ 

double  *tilt;  /*  initial  tilt  angle  in  radians  */ 

int  *fovy;  /*  initial  field  of  view  in  tenths  of  degrees  */ 

Coord  alt;  /*  initial  altitude  of  missile    */ 

int  greyscale;  /*  initial  value  of  greyscale  boolean  */ 

float  compassdir;  /*  initial  compass  direction  */ 


< 


*pan  =  INIT  PAN  *  DTOR; 
*tilt  =  INIT  TILT  *  DTOR; 
*fovy  =  INIT  FOVY; 

/*  set  initial,  min,  and  max  values  for  mouse  &  dials  */ 

setvaluator(MOUSEX,(short)(INIT   PAN*PANSENS),(short)(MIN _PAN*PANSENS), 
(short)(MAX_PAN*PANSENS)); 

setvaluator(MOUSEY,(short)(INIT_TILT*TILTSENS),(short)(MIN_TILT*TILTSENS), 
(short)  (MAX  TILT*TILTSENS) ); 

setvaluator(DIALO,(short)(compassdir*DIRSENS),  (short)(-360*DIRSENS), 
(short)(720*DIRSENS)); 

setvaluator(DIAL4,(short)alt,MIN_ALT,MAX   ALT); 

setvaluator(DIAL2,  (short)(INIT_SPEED*SPEEDSENS), 
(short)  (MIN_SPEED*SPEEDSENS), 
(short)(MAX_SPEED*SPEEDSENS)); 

set  valuator  (DIAL3,  grey  scale,  0,1); 
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INIT   IRIS 


/*  Initialize  the  graphics  environment  for  the  iris  workstation    */ 


/  *  graphics  definitions     */ 
/*  monitor  type  definitions  */ 
/*  fogm  constants    */ 


include  "gl.h" 
include  "get.h" 
include  "fogm.h" 

in 
{ 

it   iris() 
long 

chunk; 

ginit(); 
doublebuffer(); 
chunk  =  128; 
chunksize(chunk); 
gconfig(); 
if  (TV)  { 

setmonitor(NTSC); 

fontdef(l,"TV.font"); 

font(l); 

} 

else  setmonitor(HZ60); 

cursoff();  /*  turn  off  the  cursor 


/*  number  of  bytes  be  which  objects 
increment    */ 

/*  initialize  the  IRIS  system  */ 

/*  put  the  IRIS  into  double  buffer  mode     */ 


/*  (means  use  the  above  command  settings)  */ 

/*  choose  tv  or  SGI  monitor  */ 


backface(TRUE); 

color(BLACK); 

clear(); 

swapbuffers(); 


/*  turn  on  backface  polygon  removal  */ 
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INIT   TGTS 


#include  "fogm.h" 
#include  "gl.h" 

init   tgts() 

{ 

extern  short  tgt   total; 

extern  Object  taxget[99)(99]; 

short  x,  y; 

int  init   tgt ( ) ; 


for 
if( 


(x  =  0;  x  <  99;  x++)  for  (y  =  0;  y  <  99;  y+  +  )  target[x][y]  =  0; 


INETWORKING)  { 
tgt   total  =  10; 


init 
init 


init 
init 
init 
init 
init 
init 
in 


tgt 
tgt 
tgt 
tgt 
tgt 
tgt 
tgt 
tgt 
t  tgt 
init  tgt 


(0,9.8,3.5,1295) 
(1,9.5,3.5,1295) 
(2,9.4,3.1,1295) 
(3,9.8,0.5,1800) 
(4,9.5,0.0,1355) 
(5,8.0,0.0,1445) 
(6,4.0,0.0,1450) 
(7,0.0,0.5.450); 
(8,9.5,9.8,2700) 
(9,9.8,8.5,1800) 


init   tgt  (tgt   num,xoffset,zoffset, direction) 

short  tgt   num,  direction; 
float  xoffset,  zoffset; 


I 


extern  short  tgt   dir[MAX  TGTS]; 
extern  float  tgt   pos[MAX_TGTS][3]; 

tgt  posltgt_num]]0]  =  xoffset  *  FEETPERGRID; 
tgt_pos(tgt_num](2]  =  -zoffset  *  FEETPERGRID; 
tgt   dirjtgt   num]  =  direction; 
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INTERP   ELEV 


#include  "math.h" 

#define  X  0 
#define  Y  1 
#define  Z        2 

float  interp   elev(line  start,  line  end,  point) 

float  line  start[3],  line  end[3],  point[3]; 

{ 

long  float  line   deltax,  line  deltaz,  point   deltax,  point   deltaz; 

float  line   length,  dist   to   point; 

float  interpolation; 

line   deltax  =  (long  float)(line   end[X]  -  line   start[X]); 
line   deltaz  =  (long  float)(line   end[Z)  -  line  start[Z]); 

point   deltax  =  (long  float)(line   start [X]  -  pointjX]); 
point   deltaz  =  (long  float)(line_start[Z]  -  point[Z]); 

line   length  =  (float)hypot(linedeltax,  line   deltaz); 

dist   to   point  =  (float)hypot(point   deltax,  point   deltaz); 

interpolation  =  line   start[Y]  +  ((line   end[Y]  -  line   start[Yj)  * 
(dist   to   point/line   length)); 

return  (interpolation); 
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LIGHTORIENT 


/*  this  is  file  lightorient.c  */ 

/* 

It  is  a  routine  that  computes  lighting  for  a  polygon  based 
upon  the  angle  between  the  Normal  vector  of  the  polygon 
and  the  direction  to  the  light  source. 

lightorient(xyz,ncoords,ax,ay,az,lx,ly,lz,colormin,colormax,colortouse) 

xyz[][3]  =  floating  coords  of  the  polygon. 

ncoords  =  number  of  coordinates. 

ax,ay,az  =  interior  point  of  the  whole  object.  Used  to  determine 
outward  facing  normal  of  the  polygon.  This  is  the  same 
point  of  reference  that  would  be  used  for  backface 
polygon  removal. 

lx,ly,lz  =  vector  pointing  in  direction  of  the  light  source. 

colormin,  colormax  =  indices  used  for  the  colors  assigned  to  this 
polygon.  The  user  is  responsible  for  setting 
up  the  color  ramp. 

colortouse  =  returned  color  used  to  light  the  polygon. 

Note:  the  routine  also  puts  the  polygons  out  ordered  counterclockwise 
with  respect  to  the  interior  point  for  ease  of  backface  polygon 
removal. 

7 

^include  <math.h> 

^include  <gl.h> 

#define  MAXCOORDS  80 

#define  PIDIV2  1.570796327 

float  txyz[MAXCOORDS][3j;     /*  temp  coord  hold  */ 

lightorient(xyz,  ncoords, ax, ay, az,lx,ly,lz, colormin, colormax, colortouse) 

float  xyz[j[3]; 
long  ncoords; 
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float  ax,ay,az;     /*  interior  point  of  the  whole  object.  */ 

float  lx,ly,lz;     /*  direction  to  the  light  source  */ 

long  colormin,colormax;     /*  color  min/max  indices  */ 

long  *colortouse;  /*  color  used  to  light  the  polygon  (return  value)  */ 

{ 

long  i,j;     /*  loop  temps  */ 

long  npoly   orient();     /*  direction  test  function  */ 

float  vl[3],v2[3]; 


float  normal[3]; 
float  normalrnag; 
float  lightmag; 
double  dotprod; 
float  radians; 


/*  vectors  used  to  compute 
the  polygon's  normal  */ 

/*  the  polygon's  normal  */ 
/*  normal's  magnitude     */ 

/*  magnitude  of  the  light  vector  */ 

/*  dot  product  of  N  and  L  */ 
/*  angle  between  N  and  L  */ 


/*  check  the  number  of  coords  in  the  input  array  */ 
if(ncoords  >  MAXCOORDS) 

{ 

printf("LIGHTORIENT:  too  many  coords  passed  to  me!  =  %d0, ncoords); 
exit(l); 

} 

/*  orient  the  polygon  so  that  its  counterclockwise  with  respect 
to  the  interior  point  */ 

if(npoly   orient(ncoords,xyz,ax,ay,az)  ==  1) 

{ 

/*  the  polygon  is  clockwise,  reverse  it.  */ 
for(i=0;  i  <  ncoords;  i=i+l) 

{ 

for(j=0;j  <  S;j=j+1) 

{ 

txyz[i][jj  =  xyz[ncoords-i-l][j]; 

} 
} 

for(i=0;  i  <  ncoords;  +  +  i) 
for  (j=0;j  <  3;  ++j) 

xyz(i][j]  =  txyz[ij[j]; 
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} 

/*  the  coordinates  are  ordered  counterclockwise  in  array  xyz  */ 

/*  compute  the  normal  vector  for  the  polygon  using  the  first 
three  vertices...*/ 

/*  compute  the  first  vector  to  use  in  the  computation  */ 

vl[0]  =  xyz[2][0)  -  xyz[l][0] 
vl[l]  =  xyz[2][l]  -  xyz[l][l] 
vl[2]  =  xyz[2][2]  -  xyz[l][2] 

/*  compute  the  second  vector  to  use  in  computing  the  normal  */ 

v2[0]  =  xys[0][0]  -  xyz(l][0] 
v2[l]  =  xyz[0][l]  -  xyz[l][l] 
v2[2]  =  xyz[0][2]  -  xyz[l][2] 

/*  the  normal  is  vl  x  v2  */ 
normaljO]  =  vl[l]*v2[2]  -  vl(2]*v2[l]; 
normaljl]  =  vl[2]*v2[0]  -  vl[oj*v2[2J; 
normal|2]  =  vl[0]*v2[l]  -  vl[l]*v2[0j; 

/*  compute  the  magnitude  of  the  normal  */ 

normalmag  =  sqrt((normal[0{*normal[0')  +  (normal[l]*normal[l))  + 
(normal}  2]  *normal}2])); 

/*  check  the  magnitude  of  the  normal  */ 
if(normalmag  ==  0.0) 

{ 

normalmag  =  0.00001;  /*  a  small  number  */ 

} 

/*  compute  the  light  mag  */ 

lightmag  =  sqrt((lx*lx)  +  (ly*ly)  +  (lz*lz)); 

if(lightmag  ==  0.0) 

{ 

lightmag  =  0.00001;    /*  a  small  number  */ 

} 

/*  compute  N  .  L  (normal  dot  product  with  the  light  source  direction)  */ 
dotprod  =  (normal[0]  *  lx)  +  (normaljl]  *  ly)  +  (normalj2j  *  lz); 

dotprod  =  dotprod/(lightmag*normalmag); 

/*  dotprod  =  cos(theta)  of  the  angle  between  N  and  L. 

Convert  to  angle  in  radians  */ 
radians  =  acos(dotprod); 

/*  compute  the  color  we  should  use  */ 
if(-PIDIV2  <=  radians  &&  radians  <=  PIDIV2) 

{ 
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/*  if  the  angle  is  negative,  set  to  positive  */ 
if(radians  <  0.0) 

{ 

radians  =  -radians; 

} 

*colortouse  =  ((colormax-colormin)/PIDIV2)*(PIDIV2-radians)+colormin; 

} 
else 

{ 

*colortouse  =  colormin; 

I 

/*  set  the  color  */ 
color(*colortouse); 

/*  draw  the  poly  */ 

/*  polf(ncoords,txyz);  */ 
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LINE   INTERSECT2 


#include  "gl.h" 

#define  X     0 
#define  Z     2 
#define  NONE   0 
#define  INTERSECT    1 
#define  PROPER        2 


line   intersect2(startl,  endl,  start2,  end2,  intersect, 
intersect    type) 

float  startlj3],  endl(3j,  start2[3],  end2[3],  intersect[3]; 
int  *intersect   type; 


{ 


/*  given  two  lines  of  the  form  z  =  mx  +  b    and    z  =  nx  +  c, 
solving  for  x  when  the  z's  are  equal  gives  x  =  (c-b)/(m-n). 
Then  solve  for  z  using  x  in  either  of  the  above  equations.  */ 

float  m,n,b,c; 

float  mini   x,  min2   x,  maxl    x,  max2   x,  mini   z,  min2   z,  maxl   z,  max2   z; 

*intersect_type  =  PROPER; 

/*  slope  and  z  intercept  of  linel  */ 
if  (endl[X)  !=  startl(Xj)  { 

m  =  (endlJZj  -  startl[Z))/(endl[X]  -  startl[X]); 

b  =  ((startl[Zj  -  endl[Zj)/(endl[Xj  -  startl[Xj))  *  startl[X]  +  startl[Z]; 
if  (end2(Xj  !=  start2[Xj)  {    /*  both  lines  are  non-vertical  */ 
/*  slope  and  z  intercept  of  line2  */ 
n  =  (end2(Z]  -  start2[Zl)/(end2[X]  -  start2[X]); 
c  =  ((start2[Zl  -  end2[Z])/(end2[X|  -  start2iX]))  *  start2[X]  + 
start2[Z]; 

if  (m  !=  n)  { 

intersect(X)  =  (c-b)/(m-n); 
intersectjZ]  =  m*intersect[X]  +  b; 

} 

else  {    /*  both  lines  have  equal  slopes  */ 
intersect   type  =  NONE; 

} 
} 
else  {  /*  linel  is  non-vertical,  line2  is  vertical  */ 

intersect[X]  =  end2[Xj; 

intersect[Z]  =  m*intersect[X)  +  b; 

} 

} 
else  { 
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if  (end2[X]  !=  start2[X])  {  /*  linel  is  vertical,  line2  is  non-vertical*/ 
/*  slope  and  z  intercept  of  line2  */ 
n  =  (end2[Z)  -  start2[Z])/(end2[X]  -  start2[X|); 
c  =  ((start2(Z]  -  end2[Z])/(end2[X]  -  start2[X]))  *  start2[X]  + 

start2[Zj; 
intersect[X)  =  endl[X]; 
intersect[Z]  =  n*intersect[X]  +  c; 

} 

else  {    /*  both  lines  are  vertical  */ 

*intersect_type  =  NONE; 
} 
} 
if  (*intersect_type  !=  NONE)  { 

/*  see  if  the  intersection  is  proper,  or  if  only  the  extensions  of  the 

line  segments  intersect  */ 
if  (startl[X)  <  endl[X])  { 
minlx  =  startl[X]; 
maxlx  =  endl[X]; 

} 
else  { 

mini   x  =  endl[X]; 

maxl   x  =  startl[X]; 

} 

if  (startl(Z]  <  endl[Z])  { 

mini   z  =  startljZ]; 

maxl    z  =  endljZ]; 

} 
else  { 

mini   z  =  endl[Z]; 

maxlz  =  startllZ]; 

} 

if  (start2|X]  <  end2jXj)  { 

min2   x  =  start2(X]; 

max2   x  =  end2[X); 

} 
else  { 

min2_x  =  end2[X]; 

max2_x  =  start2[X]; 

} 

if  (start2(Z]  <  end2|Z])  { 

min2_z  =  start2[Z]; 

max2   z  =  end2[Zj; 

} 
else  { 

min2_z  =  end2[Z]; 

max2_z  =  start2[Z]; 

} 
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if  ((intersect[X|  <=  maxl   x)  &&  (intersectjX]  <=  max2   x)  && 
(intersectjX]  >=  minl_x)  &&  (intersectjX]  >=  min2   x)  && 
(intersectjZj  <=  maxl   z)  <fc&  (intersect[Z]  <=  max2   z)  && 
(intersectjZ]  >=  mini   z)  &&  (intersect[Z]  >=  min2   z))  { 

*  intersect   type  =  PROPER; 

} 
else  { 

*intersect_type  =  INTERSECT; 

} 
} 
} 
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MAKENAVBOX 


/*  drawnavbox.c  -  this  function  is  called  by  the  FOG-M  missile  simulator  to 
build  an  object  on  top  of  the  contour  map  in  the  upper  right-hand  corner 
of  the  screen.  Navbox  contains  the  direction  arrow  and  view  box  in  red.  */ 

#include  "gl.h" 
^include  "fogm.h" 
^include  "device. h" 

drawnavbox(navbox,  arrowtag) 
Object  *navbox; 
Tag       *arrowtag; 

{ 

*navbox  =  genobj();    /*  create  the  navigation  contol  and  display  object  */ 

makeobj(*  navbox); 

if  (TV)  viewport(475,635, 323,474); 

else  viewport(768, 1023, 512, 767);    /*    upper  right  hand  corner  of  screen  */ 

pushmatrix();  /*  draw  arrow  in  feet  coordinates  */ 

ortho2(-10.0,10.0  +  NUMXGRIDS*FEETPERGRID,  -10.0, 

-10.0  -  NUMZGRIDS*FEETPERGRID); 

color(BLACK); 

clear(); 

color(l28); 

*arrowtag  =  gentagQ; 

maketag(  *  arrowtag) ; 

move2(0. 0,0.0); 

draw2(0. 0,0.0); 

draw2(0. 0,0.0); 

move2(0. 0,0.0); 

draw2(0.0,  0.0); 

rect(0.0, 0.0,0.0,0.0);  /*    view  box    */ 

popmatrix(); 

closeobj(); 
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MAKEINDBOX 


/*  makeindbox.c  is  a  function  that  creates  an  object  that  displays  the  control 
idicators  for  the  FOG-M  missile  simulation  */ 

#include  "gl.h" 
^include  "fogm.h" 

makeind  box  ( ind  box,  head  in  g  t  ag,elevtag,altmsltag, speed  tag, zoom  tag,  tilt  tag,  pan  tag,desigtag) 

Object  *indbox; 

Tag  *headingtag,  *elevtag,  *speedtag,  *zoomtag,  *tilttag,  *pantag,  *desigtag; 

Tag  *altmsltag; 

{ 

*indbox  =  genobj(); 

makeobj(*indbox); 

if  (TV)  viewport(475,635,162,322); 

else  viewport(768, 1023, 256, 511);  /*  middle  box  on  side  of  screen  */ 

pushmatrix(); 

ortho2(0. 0,255. 0,0. 0,255.0);         /*  use  screen  sized  coordinates  */ 

color(854);  /*  clear  the  window  */ 

clear(); 

linewidth(2); 

color(BLACK); 

recti(0, 0,255, 255);  /*  outline  box  */ 

color(YELLOW);  /*  print  labels  for  readouts      */ 

cmov2i(l0,240); 

charstr("SPEED"); 

cmov2i(55,225); 

charstr("kts"); 

cmov2i(90,240); 

charstr("HEADING"); 

circ(140.0,232.0,3.0);  /*  "degree"  symbol  */ 

cmov2i(180,240); 

charstr("Alt  AGL"),    /*  AGL  =  above  ground  level  */ 

cmov2i(225,225); 

charstr("ft"); 

cmov2i(180,200); 

charstr("Alt  MSL");    /*  MSL  =  mean  sea  level        */ 

cmov2i(225,185); 

charstr("ft"); 

cmov2i(50,130); 

charstr("ZOOM"); 

move2i(45,200);  /*  draw  slider  bar  frame     */' 

draw2i(25,200); 

draw2i(25,70); 

draw2i(45,70); 

cmov2i(15,196); 

188 


charstr("8");      /*  label  slider  bar  values  */ 

cmov2i(6,170); 

charstr("15"); 

cmov2i(6,144); 

charstr("25"); 

cmov2i(6,118); 

charstr("35"); 

cmov2i(6,92); 

charstr("45"); 

cmov2i(6,66); 

charstr("55"); 


/*  readouts  in  white...  */ 

/*  initialize  to  dummy  values     */ 


/*    speed    */ 


/*  heading  */ 


/*  altitude  above  ground  level  */ 


color(  WHITE); 
cmov2i(l0,225); 
*speedtag  —  gentag(); 
maketag(*speedtag); 
charstr("  200"); 

cmov2i(l08,225); 
*headingtag  =  gentag(); 
maketag(*headingtag); 
charstr("    0"); 

cmov2i(l80,225); 
*elevtag  =  gentag(); 
maketag(*elevtag); 
charstr("1000"); 

cmov2i(l80,185); 
*altmsltag  =  gentag(); 
maketag(*altmsltag); 
charstr("1000"); 

color(RED); 

*zoomtag=  gentag(); 

maketag(*  zoom  tag); 

move2(28.0,135.0); 

rdr2(l0.0,5.0); 

rdr2(0.0,-10.0); 

rdr2(-10.0,5.0); 

popmatrix(); 


if  (TV)  viewport(0, 474, 0,474);      /*  reset  for  heads-up  display  */ 
else  viewport(0, 767, 0,767); 

pushmatrix(); 

ortho2(0. 0,767. 0,0. 0,767.0);         /*  use  screen  sized  coordinates  */ 

color(WHITE); 


/*  altitude  from  mean  sea  level  */ 


/*  indicator  for  zoom  slider  bar  */ 
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if  (TV)  linewidth(2); 
else  linewidth(l); 


/*  draw  center  of  crosshairs      */ 


rectfi(365,370,370,375) 

rectfi(396,370,401,375) 

rectfi(365, 391, 370,396) 

rectfi(396,391,401,396) 

move2i(0,383); 

draw2i(360,383);  /*  draw  crosshairs  */ 

move2i(406,383); 

draw2i(767,383); 

move2i(383,0); 

draw2i(383,365); 

move2i(383,401); 

draw2i(383,767); 

linewidth(2); 

move2i(30,50);  /*  draw  TILT  slider  bar  frame     */ 

draw2i(40,50); 

draw2i(40,680); 

draw2i(30,680); 

cmov2i(0,676); 

charstr("+25");       /*  label  slider  bar  values         */ 

cmov2i(0,613); 

charstr(M+20"); 

move2i(30,617); 

draw2i(40,617); 

cmov2i(0,550); 

charstr("  +  15"); 

move2i(30,554); 

draw2i(40,554); 

cmov2i(0,487); 

charstr("  +  10"); 

move2i(30,491); 

draw2i(40,491); 

cmov2i(0,424); 

charstr("  +5"); 

move2i(30,428); 

draw2i(40,428); 

cmov2i(0,361); 

charstr("    0"); 

move2i(30,365); 

draw2i(40,365); 

cmov2i(0,298); 

charstr("  -5"); 

move2i(30,302); 

draw2i(40,302); 

cmov2i(0,235); 

charstr("-10"j; 

move2i(30,239); 

draw2i(40,239); 
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cmov2i(0,172); 

charstr("-15"j; 

move2i(30,176); 

draw2i(40,176); 

cmov2i(0,109); 

charstr("-20"j; 

move2i(30,113); 

draw2i(40,113); 

cmov2i(0,46); 

charstr(M-25M); 

*tilttag  =  gentag(); 
maketag(*tilttag); 
move2(42. 0,365.0); 
rdr2(10.0,-5.0); 
rdr2(  0.0,10.0); 
rdr2(-8.0,-4.0); 
rdr2(  6.0,-3.0); 
rdr2(  0.0,  4.0); 
rdr2(-2.0,-1.0); 
rdr2(  1.0,-1.0); 


/*  indicator  for  TILT  slider  bar  */ 


move2i(120,15); 

draw2i(120,25); 

draw2i(750,25); 

draw2i(750,15); 

cmov2i(l07,3); 

charstr("-25"j; 

cmov2i(170,3); 

charstr("-20"); 

move2i(l83,15); 

draw2i(183,25); 

cmov2i(233,3); 

charstr("-15"); 

move2i(246,15); 

draw2i(246,25); 

cmov2i(296,3); 

charstr("-10"j; 

move2i(309,15); 

draw2i(309,25); 

cmov2i(363,3); 

charstr("-5"); 

move2i(372,15); 

draw2i(372,25); 

cmov2i(431,3); 

charstr(M0"); 

move2i(435,15); 

draw2i(435,25); 

cmov2i(494,3); 

charstr("  +  5"); 

move2i(498,15); 

draw2i(498,25); 


/*  draw  PAN  slider  bar  frame      */ 


/*  label  slider  bar  values 
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cmov2i(552,3); 
charstr("+10") 
move2i(561,15) 
draw2i(561,25) 
cmov2i(615,3); 
charstr("  +  15") 
move2i(624,15) 
draw2i(624,25) 
cmov2i(678,3); 
charstr("+20") 
move2i(687,15) 
draw2i(687,25) 
cmov2i(741,3); 
charstr("+25") 


*pantag  =  gentag(); 
maketag(*pantag); 
move2(435. 0,27.0); 


/*  indicator  for  PAN  slider  bar  */ 


rdr2 
rdr2 
rdr2 
rdr2 
rdr2 
rdr2 
rdr2 


5.0,10.0); 
-10.0,  0.0); 

4.0,-8.0); 

3.0,  6.0); 
-4.0,  0.0); 

1.0,-2.0); 

1.0,  1.0); 


move2i(0,30); 

draw2i(100,30); 

draw2i(l00,0); 

*desigtag  =  gentag(); 

maketag(*desigtag); 

cmov2i(10,10); 

charstr('»DESIGNATE"); 


/*  designate/reject  box  */ 


popmatrix(); 
closeobj(); 
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MAKEINSTRBOX 


/*  makeinstrbox.c  -  this  function  builds  an  object  that  contains  an  instruction 
summary  for  the  FOG-M  missile  simulation  */ 

#include  "gl.h" 
^include  "fogm.h" 

makeinstrbox(instrbox) 

Object  *instrbox; 

{ 

*instrbox  =  genobjQ; 

makeobj(*instrbox); 

if  (TV)  viewport(475,635,0,16l); 

else  viewport(768, 1023,0,255);        /*  box  is  in  lower  right  hand  corner  */ 

pushmatrix(); 

ortho2(0. 0,255. 0,0. 0,255.0);  /*  use  screen-sized  coordinates         */ 


color(851); 

clear(); 

linewidth(2); 

color(852); 
rectfi(10, 20,110,195); 
rectfi(135, 80,245, 195); 
color(BLACK); 
recti(10,20,110,195); 
recti(l35, 80,245, 195); 
recti(0,0,255,255); 


/*  use  a  medium  green 


/*    use  light  brown  */ 

/*    draw  the  mouse  control  box    */ 
/*    draw  the  dial  control  box     */ 
/*    outline  controls  */ 
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color(BLACK); 

cmov2i(60,230); 

charstr("C  ONTROL  S") 

cmov2i(37,200); 

charstr(  "MOUSE"); 

cmov2i(l72,200); 

charstr("DIALS"); 

cmov2i(25,60); 

charstr("TILT"); 

move2i(70,62) 

draw2i(75,55); 

draw2i(75,75); 

draw2i(70,68) 

move2i(75,75); 

draw2i(80,68) 

move2i(75,55); 

draw2i(80,62l 


/*  draw  arrow  */ 
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cmov2i 

charstr 

move2i 

draw2i( 

draw2i( 

draw2i( 

move2i| 

draw2i( 

move2il 

draw2i( 


25,30); 

"PAN") 

;67,40); 

60,35); 

80,35); 

73,40); 

;  80,35); 

73,30); 

[60,35); 

67,30); 


color(853); 
rectfi(20,85,40,185); 
rectfi(50,85, 70,185); 
rectfi(80,85,100,185) 
color(BLACK); 
recti(20, 85, 40,185); 
recti(50,85.70,185): 
recti(80,85,100.185); 


/*  draw  arrow  */ 


/*  dark  brown 
/*  draw  mouse  buttons 


/*  outline  buttons 


/*  draw  dials 


/*  outline  dials 


color(853); 

circfi(l60,165,20) 

circfi(160,110,20) 

circfi(220,165,20) 

circfi(220,110,20) 

color(BLACK); 

circi(l60,165,20); 

circi(160,110,20); 

circi(220, 165,20); 

circi(220, 110,20); 

color(WHITE); 

cmov2i(147,160); 

charstr)  "SPD");    /*  label  dials  */ 

cmov2i(147,106); 

charstr("DIR"); 

cmov2i(207,106); 

charstr("ALT"); 

cmov2i(207,160); 

charstr("CLR"); 


*/ 


cmov2i(25,170); 

charstr("Z");        /' 

cmov2i(25,158); 

charstr("0"); 

cmov2i(25,146); 

charstr("0"); 

cmov2i(25,134); 

charstif'M"); 

cmov2i(25,110); 

charstr("I"); 

cmov2i(25,98); 

charstr("N"); 


label  mouse  buttons  */ 
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cmov2i(55,170); 

charstif'D"); 

cmov2i(55,158); 

charstif'E"); 

cmov2i(55,146); 

charstr("S"); 

cmov2i(55,134); 

charstr("I"); 

cmov2i(55,122); 

charstr("G"); 

cmov2i(85,170); 

charstr("Z"); 

cmov2i(85,158); 

charstr("0"); 

cmov2i(85,146); 

charstr("0"); 

cmov2i(85,134); 

charstr("M"); 

cmov2i(85,110); 

charstr("0M); 

cmov2i(85,98); 

charstr(MU*'); 

cmov2i(85,86); 

charstr("T"); 

popmatrix(); 
closeobj(); 
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MAKEMAP 


/*  makemap.c  -  this  function  is  called  by  the  FOG-M  missile  simulator  to 
build  an  object  containing  a  contour  map.  The  map  is  used  for  the  full 
screen  display  in  prelaunch,  and  in  the  upper  right  corner  of  the  flight 
display  in  fogm.  */ 

#include  "gl.h" 
^include  "fogm.h" 
^include  "device. h" 

makemap  (con  tour) 
Object  *contour; 

{ 

short  i,  j,  elev,  length,  lastcolor,  breakpt[l5]; 

int  colour; 

extern  short  gridpixel[l00][l00];  /*  terrain  elevations  &  vegetation  */ 

/*  compute  elevations  where  color  changes  should  occur  */ 

for  (i  =  1;  i  <  16;  i+  +  )  breakpt[i-l]  =  (((MAX  -  MIN)  /  16  )  *  i)  +  MIN; 

*contour  =  genobj();    /*  create  the  navigation  contol  and  display  object  */ 

makeobj(*  contour); 

viewport(0, 767, 0,767); 

pushmatrix(); 

ortho2(0. 0,100. 0,0. 0,100.0);      /*  use  array  index  space  */ 

color(BLACK); 
clear(); 

lastcolor  =  BLACK; 
linewidth(8); 


raw  column  i 
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for  (i=0;  i  <  100;  +-H)  {  /*  d 

move2i(i,0);  /*  start  at  bottom  of  column 

length  =  0;  /*  #  adjacent  points  of  the  same  color  */ 

for  (j  =  0;  j  <  100;  +  +j)  {  /*  for  each  row  in  column  i  */ 
elev  =  gridpixeljj]  ji)  &  elev  mask;  /*  mask  off  veg  code 
if  (elev  <  breakptjO])  colour  =  16;     /*  assign  green  colors 


*/ 
/ 


else  if  (elev  <  breakpt 
else  if  (elev  <  breakpt 
else  if  (elev  <  breakpt 
else  if  (elev  <  breakpt 
else  if  (elev  <  breakpt 
else  if  (elev  <  breakpt 
else  if  (elev  <  breakpt 
else  if  (elev  <  breakpt 
else  if  (elev  <  breakpt 
else  if  (elev  <  breakpt 
else  if  (elev  <  breakpt 
else  if  (elev  <  breakpt 


1])  colour  =  17 
2])  colour  =  18 
3])  colour  =  19 
4])  colour  =  20 
5])  colour  =  21 
6])  colour  =  22 
7])  colour  =  23 
8])  colour  =  24 
9])  colour  =  25 
10))  colour  =  26; 
11])  colour  =  27; 
12     colour  =  28; 
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else  if  (elev  <  breakpt[13))  colour  =  29; 
else  if  (elev  <  breakptJH])  colour  =  30; 
else  colour  =  31; 

/*  if  veg-code  =  0  (i.e.  veg  <  1  meter)  shift  to  brown  colors  */ 
if  (!((gridpixel[j][ij  >>  13)  &  veg_mask))  colour  +=  16; 

if  (colour  ==  lastcolor)  length  +  +  ;     /*  don't  draw  yet  */ 
else  {  /*  draw  now  that  color  has  changed  */ 

color(lastcolor); 

rdr2i(0, length); 

lastcolor  =  colour;  /*  reset  for  new  draw  */ 

length  =  1; 

} 
}  /*  end  for  j  */ 

color(colour);  /*  draw  last  (top)  line  */ 

rdr2i(0, length); 
}  /*  end  for  i  */ 

if  (!TV)  { 

color(BLACK);  /*  draw  grid  on  top  of  map  */ 

linewidth(l); 

for  (i  =  10;  i  <  100;  i+=10)  {    /*  draw  interior  lines  */ 
move2i(i,0);  /*  horizontals  */ 

draw2i(i,100); 

move2i(0,i);  /*  verticals     */ 

draw2i(100,i); 
} 
} 

linewidth(2);  /*  draw  exterior  border  */ 

rect(0. 0,0. 0,100.0, 100.0); 

popmatrix(); 
closeobjQ; 
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MAKESCREENS 


/*  makescreens.c   -    builds  graphical  objects  for  prelaunchs  instructional 
screens  and  readout  boxes.  */ 

^include  "gl.h" 
#include  "device. h" 
#include  "fogm.h" 


makescreens(obj,tag) 

Object  obj(7]; 

Tag      tag[6]; 


{ 


obj[INSTR|  =  genobj(); 

makeobj(obj  INSTR]); 

if  (TV)  viewport(475,635, 239,474); 

else  viewport(767. 1023, 385, 767); 

pushmatrix(); 

ortho2(0.0,255.0,0. 0,384.0); 

color(CYAN); 

clear(); 

color(BLUE); 

rectfi(10,10,245,374); 

color(  WHITE); 


/*  object  for  pre-launch  instructions  */ 


cmov2i 

charstr 

cmov2i 

charstr 

cmov2i 

charstr 

cmov2i 

charstr 

cmov2i 

charstr 

cmov2i 

charstr 

cmov2i 

charstr 

cmov2i 

charstr 

cmov2i 

charstr 

cmov2i 

charstr 

cmov2i 

charstr 

popmatrix(); 

closeobj(); 


30,340); 

"PRE-LAUNCH  INSTRUCTIONS") 

25,300); 

"1.  PRESS  LEFT  MOUSE"); 

52,285); 

"BUTTON  TO  LOCK  IN"); 

52,270); 

"LAUNCH  POSITION"); 

25,220); 

"2.  PRESS  RIGHT  MOUSE"); 

52,205); 

"BUTTON  TO  LOCK  IN"); 

52,190); 

"TARGET  LOCATION"); 

25,140); 

"3.  PRESS  MIDDLE  MOUSE"); 

52,125); 

"BUTTON  TO  LAUNCH"); 

25,  75); 

"4.  PRESS  ALL  THREE"); 

52,  60); 

"BUTTONS  TO  EXIT"); 
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/*  define  object  for  displaying  user  input  for  missile  launch 

position  and  target  location.  Also  displays  computed  heading 
and  distance  to  target  */ 

obj  [STATS]  =  genobj(); 

makeobj(obj  [STATS]); 

if  (TV)  viewport(475, 635, 0,238); 

else  viewport(767, 1023, 0,384); 

pushmatrix(); 

ortho2(0.0,255.0,0.0,384.0); 

color(CYAN); 

clearQ; 

color(BLUE); 

rectfi(l0,10,245,374); 

color  ( WHITE); 

cmov2i(30,340); 

charstr("PRE-LAUNCH  STATISTICS"); 

cmov2i(25,260); 

charstr("LAUNCH  POSITION:  10SFQ"); 

cmov2i(70,235); 

charstr("X  COORD:  "); 

cmov2i(70,220); 

charstif'Y  COORD:  "); 

cmov2i(  170,235); 

tag[LAUNCH]  =  gentag(); 

maketag(tag[LAUNCH]); 

charstr("     "); 

cmov2i(l70,220); 

charstr("     "); 

cmov2i(25,180); 

charstr("TARGET  LOCATION:  10SFQ"); 

cmov2i(70,155); 

charstif'X  COORD:         "); 

cmov2i(70,140); 

charstif'Y  COORD:         "); 

cmov2i(170,155); 

tag[TARGET]  =  gentag(); 

maketag(tag[TARGET]); 

charstr("     »); 

cmov2i(l70,140); 

charstr("     "); 

cmov2i(25,100); 

charstr(" HEADING:  "); 

cmov2i(25,60); 

charstr("DISTANCE:  "); 

cmov2i(l06,100); 

tag[HEAD]  =  gentag(); 

maketag(tag[HEAD]); 

charstr("  "); 

cmov2i(115,60); 

charstr("     "); 

popmatrix(); 
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closeobj(); 

/*  define  object  for  lines  &  circles  showing  flightpath  on  contour  map  */ 

obj[FLTPATH]  =  genobj(); 

makeobj(obj[FLTPATH]); 

pushmatrix(); 

if  (TV)  viewport(0,474,0,474); 

else  viewport(0, 767, 0,767); 

ortho2(0.0,100.0,0.0,100.0); 

color(BLACK); 

clear(); 

color(64); 

linewidth(3); 

tag[MISSILE]  =  gentag(); 

maketag(tag[MISSILE]); 

circf(0.0,0.0,0.0); 

move2(0.0,  0.0,  0.0); 

draw2(0.0,  0.0.  0.0); 

color(l28); 

tag[TGT]  =  gentag(); 

maketag(tag[TGT]); 

circf(0.0.0.0,0.0); 

popmatrix(); 

closeobj(); 

/*  define  object  for  displaying  first  screen  of  operator  instructions  */ 

obj[SCREENl]  =  genobj(); 

makeobj(obj[SCREENl]); 

color(BLUE);  /*  set  background  color  */ 

clearQ; 

color(RED); 

linewidth(lO); 

recti(0,0,1023,767); 

linewidth(l); 

color  (WHITE); 

cmov2i(420,500); 

charstr("  WELCOME"); 

cmov2i(420,450); 

charstr("TO   THE"); 

cmov2i(320.400); 

charstri"  FIBER-OPTIC  ALLY  GUIDED  MISSILE"); 

cmov2i(420,350); 

charstr("(FOG-M)"); 

cmov2i(410,300); 

charstr("SIMULATION"); 

cmov2i(310,100); 

charstr("PRESS  MIDDLE  MOUSE  BUTTON  TO  CONTINUE..."); 

cmov2i(315,85); 

charstr("OR  PRESS  ALL  3  MOUSE  BUTTONS  TO  EXIT."); 

closeobj(); 
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/*  define  object  for  displaying  second  screen  of  operator  instructions  */ 

obj[SCREEN2]  =  genobj(); 

makeobj  (obj  JSCREEN2] ) ; 

color(BLUE);  /*  set  background  color  */ 

clear  (); 

linewidth(lO); 

color  (RED); 

recti(0,0,1023,767); 

linewidth(l); 

color  (WHITE); 

cmov2i(210,600); 

charstr("THE  FOG-M  PROGRAM  PROVIDES  A  SIMULATED  MISSILE  LAUNCH  AND"); 

cmov2i(210,575); 

charstr("OUT-THE- WINDOW  VIEW  OF  THE  TERRAIN  AS  SEEN  FROM  THE  OPERATOR'S'*); 

cmov2i(210,550); 

charstr("CONSOLE  ON  THE  GROUND."); 

cmov2i(210,500); 

charstr("THE  GENERAL  AREA  FOR  THIS  FLIGHT  SIMULATION  IS  FT  HUNTER  LIGGETT"); 

cmov2i(210,475); 

charstr("CALIFORNIA  AND  VICINITY."); 

cmov2i(210,425); 

charstr("THE  SPECIFIC  TEST  AREA  IS  A  10  KILOMETER  REGION  DESIGNATED  BY"); 

cmov2i(210,400); 

charstr("UNIVERSAL  TRANSVERSE  MERCATOR  (UTM)  GRID  COORDINATES  10SFQ58."); 

cmov2i(300,100); 

charstr("PRESS  MIDDLE  MOUSE  BUTTON  TO  CONTINUE,"); 

cmov2i(305,85); 

charstr("OR  PRESS  ALL  3  MOUSE  BUTTONS  TO  EXIT."); 

closeobj(); 

/*  define  object  for  displaying  third  screen  of  operator  instructions  */ 

obj[SCREEN3]  =  genobj(); 

makeobj  (obj  [SCREEN3]); 

color(BLUE);  /*  set  background  color  */ 

clearQ; 

Hnewidth(lO); 

color(RED); 

recti(0,0, 1023, 767); 

linewidth(l); 

color  (WHITE); 

cmov2i(385,650); 

charstr( "PRE-L A UNCH  ORIENTATION" ) ; 

cmov2i(200,600); 

charstr("l.  WHEN  THE  PRE-LAUNCH  PHASE  OF  THE  FOG-M  SIMULATION  BEGINS,  A"); 

cmov2i(200,585); 

charstr("2-DIMENSIONAL  CONTOUR  MAP  OF  THE  TEST  AREA  (UTM  10SFQ58)  WILL  BE"); 

cmov2i(200,570); 

charstr("DISPLAYED  ON  THE  OPERATOR  CONSOLE.  TWO  CONTROL  PANELS  CONTAINING"); 

cmov2i(200,555); 

charstr("PRE-LAUNCH  INSTRUCTIONS  AND  CURRENT  LAUNCH  STATISTICS  WILL  ALSO"); 
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cmov2i(200,540); 

charstr("BE  DISPLAYED."); 

cmov2i(200,490); 

charstr("2.  THE  OPERATOR  WILL  BE  REQUIRED  TO  PROVIDE  TWO  CRITICAL  DATA"); 

cmov2i(200,475); 

charstif'ITEMS  TO  THE  LAUNCH  CONTROL  SYSTEM;  INITIAL  LAUNCH  POSITION  AND"); 

cmov2i(200,460); 

charstif'TARGET  LOCATION."); 

cmov2i(200,410); 

charstr("3.  TO  DEFINE  INITIAL  LAUNCH  POSITION,  MOVE  CURSOR  OVER  DESIRED"); 

cmov2i(200,395); 

charstif'LOCATION  (REFER  TO  LAUNCH  STATISTICS  CONTROL  PANEL  TO  VIEW  THE"); 

cmov2i(200,380); 

charstr("CURRENT  UTM  GRID  COORDINATES).  PRESS  LEFT  MOUSE  BUTTON  TO  LOCK"), 

cmov2i(200,365); 

charstr("IN  LAUNCH  POSITION."); 

cmov2i(200,315); 

charstr("4.  TO  DEFINE  TARGET  LOCATION,  MOVE  CURSOR  OVER  DESIRED  LOCATION"); 

cmov2i(200,300); 

charstr("(REFER  TO  LAUNCH  STATISTICS  CONTROL  PANEL  TO  VIEW  CURRENT  UTM"); 

cmov2i(200,285); 

charstr("GRID  COORDINATES).  PRESS  RIGHT  MOUSE  BUTTON  TO  LOCK  IN  TARGET"); 

cmov2i(200.270); 

charsuf'LOCATION.  THE  BLUE  LINE  DISPLAYS  THE  PROJECTED  FLIGHT  PATH.  THE"); 

cmov2i(200,255); 

charstif'MISSILE  WILL  FLY  AT  A  CONSTANT  VELOCITY  AND  HEADING.  THE  LAUNCH"); 

cmov2i(200,240); 

charstr("STATISTICS  CONTROL  PANEL  WILL  DISPLAY  COMPUTED  MISSILE  HEADING"); 

cmov2i(200,225); 

charstr("IN  DEGREES  (0  DEGREES  DUE  NORTH)."), 

cmov2i(240,100); 

charstr("PRESS  MIDDLE  MOUSE  BUTTON  TO  MOVE  INTO  PRE-LAUNCH  PHASE,"); 

cmov2i(326,85); 

charstr("OR  PRESS  ALL  3  MOUSE  BUTTONS  TO  EXIT."); 

closeobjQ; 
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MAKETANK 


#include  "gl.h" 
^include  "fogm.h" 

maketank(item) 
Object  *item; 


{ 


long  points  =  4,  bigpoints  =  8; 

float  parray[8][3]; 

float  lx,ly,lz; 

long  cmin  =  MINTGTCOLOR,  cmax  =  MAX  TGTCOLOR,  cl; 

lx  =  400.0  *  41.01;    /*  direction  of  lightsource  */ 

ly  =  6000.0; 

lz  =  200.0  *  (-41.01); 


*item=genobj(); 
makeobj(*item); 

/*  draw  right  side  of  tank  CCW  */ 
n,[0]  =  -10.0; 


[0 


U 


parr  ay 
parray 
parray 
parray 
parray 
parray  [l 
parray  [2 
parray  [2 
parray  [2 
parray  [3 
parray  [3 
parray  [3 
parray  [4 
parray  [4 
parray[4 
parray  f  5 
parray | 5 
parray | 5 
parray  [6j[0 
parray[6][l 
parray  [6]  [2 
parray  [7]  [0 
parray[7][l 
parray  [7]  [2 


[0 


1]  =    6.0. 
2]  -  -5.0; 
0]  =  -15.0; 
1]  =   4.0; 
2]  =  -5.0; 
0]  =  -15.0; 
1]  =    2.0; 
2]  =  -5.0; 
0]  =  -10.0; 
1  =    0.0; 

=  -5.0; 

=    10.0; 

=    0.0; 

=  -5.0; 

=    15.0; 

=    2.0; 

=  -5.0; 

=    15.0; 

-    4.0; 

=  -5.0; 

=    10.0; 
6.0 
5.0; 


ya.i  i  ay  [  i      i     —     <j.u, 

parray[7][2]  =  -5.0; 

lightorient  (parray,  bigpoints,  0.0,0.0,0.0,lx,ly,lz,  cmin,  cmax,  &cl); 

color(cl); 
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polf  (bigpoints,parray) ; 

/*  front  of  tank    CW  */ 

parray[0][0]  =  15.0; 

parray[0][l]  =    5.0; 

parray[0][2]  =  -5.0; 

parray[ll[0]  =  15.0; 

parray[ljjlj  =    3.0; 

parray[l][2]  =  -5.0; 

parray[2][0]  =  15.0; 

parray[2][l]  =    3.0; 

parray[2][2]  =    5.0; 

parray[3][0]  =  15.0; 

parray[3][l]  =    5.0; 

parray[3][2|  =    5.0; 

lightorient  (parray, points, 0.0,0.0,0.0,lxdy,lz,cmin,cmax,&cl); 

color(cl); 

polf(points,parray); 

/*  draw  left  side  of  tank  CW  */ 

parray[0][0]  =    10.0; 

parray[0][lj  =    6.0; 

parray[0l[2J  =  5.0; 

parrayjljjoj  =    15.0; 

parrayjljjlj  =    4.0; 

parray[l][2j  =  5.0; 

parray[2][0]  =    15.0; 

parray[2][l]  =    2.0; 

parray[2][2)  =  5.0; 

parray[3][0]  =    10.0; 

parray[3)jl]  =    0.0; 

parray[3][2]  =  5.0; 

parray[4][0]  =  -10.0; 

parray[4][l]  =    0.0; 

parray[4][2]  =  5.0; 

parray{5][0]  =  -15.0; 

parray[5][l]  =    2.0; 

parray[5][2]  =  5.0; 

parray[6](0]  =  -15.0; 

parray[6][l]  =    4.0; 

parray[6][2]  =  5.0; 

parray[7l[0l  =  -10.0: 

parrayiTIJll   =    6.0; 

parray|7![2l  —  5.0; 

lightorient(parray,bigpoincs,0.0,0.0,0.0,lx,iy,iz,cmin,cmax,lfcclJ 

color(cl); 

polf(bigpoints,parray); 


/*  back  of  tank  CCW  */ 

parray[0](0]  =    -15.0; 
parray[0][l]  =    4.0; 
parray[0][2]  =    5.0; 
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parray[l][0 

parray[l][l 

parray[l][2 

parray[2][0 

parray[2][l 

parray[2][2 

parray[3][0 

parray[3)[l 

parray[3][2 

lightorient 

color(cl); 

polf  (points, parray); 


=    -15.0; 
=    2.0; 
=    5.0; 
=    -15.0; 
=    2.0; 
=  -5.0; 
=    -15.0; 
=    4.0; 
=  -5.0; 
parray,  points,  0.0, 0.0, 0.0,  be,  ly,lz,cmin,cmax,&cl); 


/* 


7 


top  middle  of  tank  body    CCW 
parray[0][0]  =  -10.0; 
parray[0][l]  =    6.0; 
parray  [0]  [2]  =  -5.0; 
parray[l][0]  =  -10.0; 
parray[ll[ll  =    6.0; 
parray[l][2]  =    5.0; 
parray[2][0]  =    10.0; 
parray[2][l]  =    6.0; 
parray[2][2]  =    5.0; 
parray  [31  [0j  =    10.0; 
parray[3][l]  =    6.0; 
parray[3][2j  =  -5.0; 

lightorient  (parray, points, 0.0, 0.0, 0.0, be, ly,lz,cmin,cmax, &cl); 
color(cl); 


polf  (points,  parr  ay) ; 

/*  top  front  of  tank  body    CCW  */ 

DarravfOllOl  =  10.0: 


parray  [0][ 

parray  [0][ 

parray  [0][ 

parray[l][ 

parray  [l][ 

parray  [l][ 

parray  [  2]  [ 

parray  [2]  [ 

parray[2][2 

parray[3][0 

parray  [3]  [l 

parray|3!|2)  =  -5.0; 

lightonen  t  ( parray.  points,0. 0,0. 0,0.0, 

color(cl); 

polf(points, parray); 

/*  top  back  of  tank  body    CCW  */ 

parray[0][0]  =  -10.0; 
parrayjojjl]  =    6.0; 
parray[0][2]  =  -5.0; 
parray[l][0]  =-15.0; 


0]  ==  10.0; 
1]  =  6.0; 
2]  =  -5.0; 
0]  =  10.0; 

=    6.0; 

=    5.0; 

=  15.0; 

=    4.0; 

=    5.0; 

=  15.0; 

=    4.0: 

=  -5.0; 


lx,iy,iz,cmin.crnax,&;cl) 
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parray[l](l]  =    4.0; 

parray[l][2]  =  -5.0; 

parray  [2|[0]  =  -15.0; 

parray  [2]  [l]  =    4.0; 

parray[2][2]  =    5.0; 

parray  [3j[0]  =  -10.0; 

parray[3j[l]  =    6.0; 

parray[3][2]  =    5.0; 

lightorient  (parray, points, 0.0,0.0,0.0,Lx,ly,lz,cmin,cmax,&cl); 

color(cl); 

polf  (points, parray) ; 


/*  bottom  middle  of  tank  CW*/ 
parray  [0][0]  =  -10.0; 
parrayjojjl]  =  0.0; 
parray  [0]  [2]  =  -5.0; 


parray[l][0]  =    10.0; 

parray[l][l]  =  0.0; 

parray[lj[2l  =  -5.0; 

parrayJ2J[0]  =    10.0; 

parray[2J[l]  =  0.0; 

parray[2J[2]  =    5.0; 

parray  [3]  [0]  =  -10.0: 

parray  J3i[lj  =  0.0; 

parray[3][2]  =    5.0; 

lightorient  (parray,  points,  0.0,0.0,0.0,lx,ly,lz,cmin,cmax,&:cl); 

color(cl); 

polf  (points, parray ) ; 

/*  bottom  front  of  tank  CW  */ 
parray  [0][0]  =  10.0; 
parray  [0][l]  =  0.0; 

parray[0][2]  =  -5.0; 

parray  [l][0]  =  15.0; 

parray  [l][l]  =  2.0; 

parray[l][2]  =  -5.0; 

parray  [2]  [0]  =  15.0; 

parray[2][l)  =  2.0; 

parray[2][2]  =    5.0; 

parray  [3]  [0]  =  10.0; 

parray[3][l]  =  0.0; 

parray[3][2]  =    5.0; 

iightorient(  parray.  points. 0.0,0.0,0.0.1x.ly,lz,cmin,cmax.&;cl); 

coior(cl); 

polf  (points,  parray ) ; 

/*  bottom  back  of  tank  CW  */ 
parray[0][0]  =     -10.0; 
parray  [Ojjlj  =  0.0; 
parray[0)[2]  =  -5.0; 
parray[l][0]  =     -10.0; 
parrayjljjl]  =  0.0; 
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parray[l][2]  =    5.0; 

parray[2][0]  =     -15.0; 

parray[2][l]  =  2.0; 

parray[2][2]  =    5.0; 

parray  [3]  [0]  =     -15.0; 

parray[3][l]  =  2.0; 

parray  [3]  [2]  =  -5.0; 

lightorient  (parray, points, 0.0,0.0,0.0,Lx,ly,lz,cmin,crn  ax,  &cl); 

color(cl); 

polf(points,parray); 

/*  right  side  of  gun  barrel  */ 

parray[0][0]  =  1.6667; 

parray[0][l]  =    8.0; 

parray  [0]  [2]  =   -0.5; 

parray[l][0]  =  2.3333; 

parray  [l][l]  =    7.0; 

parray  [l]  [2]  =    -0.5; 

parray  [2]  [0]  =  17.0: 

parray[2J[l]  =    7.0; 

parray[2][2]  =    -0.5; 

parray[3][0]  =  17.0; 

parray[3][li  =    8.0; 

parray[3|[2]  =    -0.5; 

lightorient(parray,points,5.0,2.5,0.0,lx,ly,lz,cmin,cmax,&;cl); 

color(cl); 

polf  (points, parray); 

/*  top  of  gun  barrel  */ 

parray  [0][0j  =  1.6667; 

parray[0][l]  =    8.0; 

parray[0][2]  =    0.5; 

parray[l][0]  =  1.6667; 

parray[l][l]  =    8.0; 

parray[l][2]  =  -0.5; 

parray  [2]  [0]  =  17.0; 

parray[2][l]  =    8.0; 

parray[2][2]  =  -0.5; 

parray[3][0]  =  17.0; 

parray[3][l]  =    8.0; 

parray[3][2]  =    0.5; 

lightorient  (parray.  points,  5. 0.2. 5, 0.0,lx,!y,lz,cmin,cmax,&cl); 

color(ci); 

poif(  points,  parr  ay); 

/*  left  side  of  gun  barrel  */ 

parray  [0][0]  =  17.0; 

parray[0][l]  =  8.0; 

parray[0][2]  =  0.5; 

parray[l][0]  =  17.0; 

parrayjljjl]  =  7.0; 

parray[lj[2]  =  0.5; 
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parray[2)[0)  =  2.3333; 

parray[2][l]  =    7.0; 

parray(2J[2]  =    0.5; 

parray[3][0]  =  1.6667; 

parray[3][l]  =    8.0; 

parray[3][2]  =    0.5; 

lightorient(  parray,  points.  5. 0,2. 5. 0.0. be, ly,lz,cmin,cmax,&:cl); 

color(cl); 

polf(points,parray); 

/*  end  of  gun  barrel  */ 
parray[0][0]  =  17.0; 

parrayiOjjl]  =    8.0; 

parray[0][2]  =  -0.5; 

parrayjljjoj  =  17.0; 

parrayjljjlj  =    7.0; 

parray[l][2]  =  -0.5; 

parray[2)[0)  =  17.0; 

parray[2][l!  =    7.0: 

parray[2j[2J  =    0.5; 

parray[3][0J  =  17.0; 

parray[3][lj  =    8.0; 

parray!3l[2!  =    0.5; 

lightorien  t(  parray,  points,  5. 0,2. 5, 0.0,lx,ly,lz,cmin,cmax,&cl); 

color(cl); 

polf(  points,  parray); 

/*bottom  of  gun  barrel  */ 

parray[0][0j  =  2.3333; 

parrayjojjl]  =    7.0; 

parray  [0]  [2]  =    0.5; 

parray[l][0]  =  2.3333; 

parrayjljjl]  =    7.0; 

parray[ljJ2J  =  -0.5; 

parray  [2][0]  =  17.0; 

parrayJ2Jjlj  =    7.0; 

parrayJ2JJ2J  =  -0.5; 

parrayJ3J[0]  =  17.0; 

parray  js][l]  =    7.0; 

parray  J3JJ2J  =    0.5; 

lightorient(  parray,  points,  5. 0,2.5, 0.0,  be,  ly,lz,cmin,cmax,&cl); 

color(cl); 

poif(points.  parray); 

/*  right  side  of  turret 
parray[0][0)  =  -3.0; 
parrayjojjlj  =  9.0; 
parrayjojJ2J  =   -1.0; 
parrayjljjoj  =  -5.0; 
parray[l][l]  =  6.0; 
parrayjljJ2]  =    -3.0; 
parrayJ2Jjoj  =    3.0; 
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parray[2][l]  =    6.0; 

parray[2][2]  =    -3.0; 

pan-ay  [S]jo]  =    1.0; 

parray[3][l]  =    9.0; 

parray[3][2]  =   -1.0; 

lightorient  (parray, points, -1.0, 2. 5, 0.0,lx,ly,lz,cmin,cmax,&;cl); 

color(cl); 

po  If  (points,  parray); 

/*  front  side  of  turret  */ 

parray[0][p]  =  1.6667; 

parrayjojjlj  =  9.0; 

parray  [0]  [2]  =  -1.0; 

parray[l][0]  =  3.0; 

parrayjljjl]  =  6.0; 

parray[l][2]  =  -3.0; 

parray[2][0]  =  3.0; 

parray[2][l]  =  6.0; 

parray  [2]  [2]  =    3.0; 

parray[3J[0]  =  1.6667; 

parray[3][l]  =  9.0; 

parray[3][2]  =    1.0; 

lightorient  (parray,  points,  -1.0,2. 5, 0.0,lx,ly,lz,cmin,cmax,&cl); 

color  (cl); 

polf(points, parray); 

/*  left  side  of  turret  */ 
parray[0][0]  =    1.6667; 

parrayjojjlj  =    9.0: 

parray[0][2]  =    1.0 

parray[l][0]  =    3.0 

parrayjljjl]  =    6.0 

parrayjljJ2J  =    3.0; 

parray  J2]  JO]  =  -5.0 

parrayJ2}jlj  =    6.0: 

parrayJ2]J2J  =    3.0 

parray  J3Jjoj  =  -3.0 

parrayJ3Jjlj  =    9.0, 

parrayJ3]J2J  =    1.0; 

lightorient  (parray,  points,  -1.0, 2. 5, 0.0,bc,ly,lz,cmin,cmax,&cl); 

color(cl); 

polf(  points,  parray); 

/*  back  side  of  turret  */ 
parray  j0j[0j  =  -3.0; 
parrayjojjlj  =  9.0; 
parrayjojJ2J  =    1.0; 
parrayjljjoj  =  -5.0; 
parrayjljjl]  =  6.0; 
parrayjljJ2]  =    3.0; 
parrayJ2]joj  =  -5.0; 
parrayJ2]jlj  =  6.0; 
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} 


parray[2][2]  =  -3.0; 

parray[3][0]  =  -3.0; 

parray[3][l]  =  9.0; 

parray[3][2]  =  -1.0; 

lightorient(parray, points,- 1.0, 2.5, 0.0,bc,ly,lz,cmin,cmax,  &cl); 

color(cl); 

polf(points,parray); 

/*  top  of  turret  */ 

paxray[0][0]  =  -3.0; 

parray[0][l]  =  9.0; 

parray[0][2]  =    1.0; 

parray[lj[0)  =  -3.0; 

parrayjljjl]  =  9.0; 

parray[lj[2]  =  -1.0; 

parray[2][0]  =    1.0; 

parray[2][l]  =  9.0; 

parray[2][2]  =  -1.0; 

parray[3][0]  =    1.0; 

parray[3][l]  =  9.0; 

parray[3][2]  =    1.0; 

lightorient(parray,points,-1.0,2.5,0.0,lx,ly,lz,cmin,cmax,&cl); 

color(cl); 

polf  (points, parray) ; 

closeobj(); 
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NEAREST  TGT 


#include  "gl.h" 
#include  "fogm.h" 

nearest_tgt(vx,vy,vz,px,py,pz,tgt_idx) 
Coord  vx,  vy,  vz,  px,  py,  pz; 
int  *tgt   idx; 


{ 


float  dist,  dist_to_los(); 

float  min_dist; 

float  num_tgts; 

extern  floa~t  tgt_pos[MAX_TGTS][S|; 

int  index; 

numtgts  =  10; 

min_dist  =  dist_to_los(vx,vy,vz,px,py,pz,&tgt_pos[0][0]); 

*tgt_idx  =  0; 

for  (index  =  1;  index  <  num_tgts;  +-findex)  { 

dist  =  dist_to_los(vx,vy,vz,px,py,pz,&:tgt_pos[index][0]); 
if  (dist  <  min_dist)  { 
min_dist  =  dist; 
*tgt_idx  =  index; 
} 
} 
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NPOLY   ORIENT 

/*  npoly_orient.c    */ 

^include  <gl.h> 
^include  <math.h> 

int  npoly  orient(ncoords,xyz,xinside,yinside,zinside) 

unsigned  int    ncoords; 

Coord  xyz[][3]; 

Coord  xinside,  yinside,  zinside; 

{ 

register  unsigned  short  int     i,j;  /*  loop  temps  */ 

Coord  center[3|;     /*  center  coordinate  of  the  polygon  */ 

Coord  a[3],  b[3j;  /*  vector  hold  locations  for  the  vectors  that  run 
from  the  center  coordinate  to  the  points  of  the 
polygon  */ 

Coord  xn|3],  xmn[3|;    /*  points  on  line  containing  normal  that  are 
on  opposite  sides  of  the  plane  containing 
the  polygon. 

7 

float  distton;  /*  distance  to  point  n  from  pt  inside.  */ 

float  disttomn;  /*  distance  to  point  -n  from  pt  inside.  */ 

Coord  normal[3];         /*  the  normal  vector  computed  from  a  x  b  */ 


/*  compute  the  center  coordinate  of  the  polygon  */ 
center[0]  =  0.0; 
centerjl]  =  0.0 
center[2]  =  0.0 

for(i=0;  i  <  ncoords;  i++) 

{ 

For(j=0;  j  <  3;  j++) 

{ 

center|j|  +=  xyzii](j|; 

I 
} 

/*  divide  out  by  the  number  of  coordinates  */ 
for(j=0;  j  <  3;  j++) 

{ 

centerjj]  =  center[j]/(float)ncoords; 

} 


212 


/*  check  the  first  2  coordinates  of  the  polygon  for  their  direction  */ 

/*  compute  vector  a.  It  runs  from  the  center  coordinate  to  coordinate  0  */ 
for(j=0;j  <  3;j++) 

{ 

a[j]  =  xyz[0][j]  -  center[j]; 

} 

/*  compute  vector  b.  It  runs  from  the  center  coordinate  to  coordinate  1  */ 
for(j=0;  j  <3;  j+ +) 

{ 

b[j]  =  xyz[l][j]  -  centerfj]; 

} 

/*  compute  a  x  b  to  get  the  normal  vector  */ 

normal[0]  =  a[l]*b[2]  -  a[2]*b[l] 
normaljl]  =  a[2]*b[0]  -  a[0]*b[2] 
normal[2]  =  a[0]*b[l]  -  a[l]*b[0] 

/*  compute  point  n,  offset  pt  from  center  in  direction  of  normal  */ 
for(j=0;  j  <  3;  j+  +  ) 

{ 

xn[j]  =  centerfj]  4-  normalfj]; 

} 

/*  compute  point  -n,  offset  pt  from  center  in  opposite  direction 
from  normal. 

7 

for(j=0;  j  <  3;  j++) 

{ 

xmn[j]  =  centerjj]  -  normaljj]; 

} 

/*  compute  the  distance  the  inside  pt  is  from  point  n  */ 
distton  =  sqrt((xn[0]  -  xinside)  *  (xn[0]  -  xinside)  + 

(xn[l]  -  yinside)  *  (xn[l]  -  yinside)  + 

(xn[2]  -  zinside)  *  (xn[2]  -  zinside)); 

/*  compute  the  distance  the  inside  pt  is  from  point  -n  */ 
disttomn  =  sqrt((xmn[0]  -  xinside)  *  (xmn[0]  -  xinside)  + 

(xmn[l]  -  yinside)  *  (xmn[l]  -  yinside)  + 

(xmnf2l  -  zinside)  *  (xmnf2l  -  zinside)); 
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/*  if  the  dist(n)  <  dist(-n),  then  n  points  back  towards  the 
inside  point  and  is  on  the  same  side  of  the  plane  as  inside. 
a  x  b  is  then  clockwise. 

_  7 

if(distton  <  disttomn) 

{ 

return(l);     /*  clockwise  */ 

} 
else 

{ 

return(O);     /*  counterclockwise  */ 

} 
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PRELAUNCH 


/*  The  function  prelaunch  is  the  user  interface  portion  of  the  FOG-M 
flight  simulation.  It  allows  the  operator  to  interactively  enter 
critical  data  items  necessary  to  simulate  the  missile  in  flight. 
The  function  returns  the  initial  launch  position  in  the  x-z  plane 
and  also  the  direction  of  flight.  */ 


#include  "gl.h" 
^include  "device. h" 
^include  "fogm.h" 
^include  "math.h" 

prelaunch(vx,  vy,  vz,  direction,  compassdir,  active,  obj,  tag) 

Coord    *vx,  *vy,  *vz; 
double  *direction; 
float  *compassdir; 
int      *active; 
Object  obj  [7]; 
Tag      tag[6l; 


{ 


float  gnd_level(); 

float  compass(); 

int    screencnt,  launchlock,  targetlock; 

int  xval,  yval,  xlaunch,  ylaunch,  xtarget,  ytarget,  utm   x,  utm  y; 

char  xtemp[35],  ytemp(35],  dist[35],  heading[35|; 

float  distance; 

double  xdistance,  ydistance; 

Colorindex  unmask; 

xtemp[0]  =  '  '; 
ytempjo]  =  '  '; 
dist[0]    =  '  '; 
heading[0]  =  '  '; 

unmask=(l<<getplanes())  -1; 
writemask  (unmask); 
•  if  (TV)  viewport(0,635, 0,474); 
else  viewport|0. 1023, 0.767); 
pushmatrixl); 
orcho2(0.0,1023.0,0.0,767.0); 

*direction  =  0.0;  /*  initialize  the  direction  */ 

cursoffQ;  /*  turn  the  cursor  off  */ 

callobj(obj[SCREENl]);  /*  display  screen  1  */ 

swapbuffersQ; 
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screencnt  =  1;  /*  initialize  counter  for  screen  displays  */ 

while(TRUE)  { 

frontbuffer(TRUE); 

if  (getbutton(MOUSE2)  &&  !(getbutton(MOUSEl))  &&  !(getbutton(MOUSE3)))  { 

ringbell(); 

while  (getbutton(MOUSE2)); 

screencnt  +=  1; 

if  (screencnt  ==  2)  callobj(obj(SCREEN2]); 

else  if  (screencnt  ==  3)  callobj(obj(SCREEN3J); 

else  break; 

} 

if  (getbutton(MOUSEl)  &&  (getbutton(MOUSE2))  &<fc  (getbutton(MOUSE3)))  { 

*active  =  FALSE; 

goto  exit; 

} 

} 

frontbuffer  (FALSE); 

editobj(obj[FLTPATHj);      /*  erase  previous  missile  path  */ 

objreplace(tag[MISSILE]); 

circf(0.0,  0.0,  0.0); 

move2(0.0,  0.0); 

draw2(0.0,  0.0); 

objreplace(tagjTGTl); 

circf(0.0,  0.0,  0.0); 

closeobj(); 

editobj(obj[STATS]);  /*  erase  previous  launch  statistics  */ 

objreplace(tag[HEAD]); 

charstr(""); 

cmov2i(H5,60); 

charstr(,M'); 

objreplace(tag[TARGET]); 

charstr(""); 

cmov2i(0,0); 

charstrC*"); 

closeobj(); 

setcursor(0, RED, unmask);  /*  set  up  cursor  and  mouse  */ 

attachcursor(MOUSEX,MOUSEY) ; 

setvaluator(MOUSEX. 384, 0,767); 

setvaiuaton  MOUSEY,  384. 0, 767); 

ourson(); 

launchlock  =  FALSE; 
targetlock  =  FALSE; 

callobj(obj[CONTOUR]);     /*  load  static  displays  into  both  buffers  */ 

callobj(obj|INSTR]); 

callobj(obj[STATS]);  /*  included  so  swapped  buffer  doesn't  have  "hole"  */ 

swapbuffers(); 
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callobj(obj  [CONTOUR]); 
callobj(obj[INSTR]); 

while(TRUE)  { 

if  (getbutton(MOUSEl)  &&  (getbutton(MOUSE2))  &&  (getbutton(MOUSE3)))  { 
*active  =  FALSE; 
goto  exit; 

} 

xval  =  getvaluator(MOUSEX);  /*  read  the  x  and  y  mouse  positions  */ 

yval  =  getvaluator(MOUSEY); 

utm_x  =  (50000  +  (int)(xval  *  GRID_FACTOR));  /*  compute  grid  coordinates  */ 
utm_y  =  (80000  +  (intjjyval  *  GRIDFACTOR)); 

sprintf(xtemp,"%4d",utm_x);        /*  store  coordinates  in  temporary  buffer  */ 
sprintf(ytemp,"%4d",utm_y); 

/*  if  LEFT  MOUSE  selected  lock  in  launch  position  and  update  control  panel  */ 

if  (getbutton(MOUSE3)  &&  (!getbutton(MOUSE2))  &&  (!getbutton(MOUSEl)))  { 

ringbell(); 

xlaunch  =  xval; 

ylaunch  =  yval; 

launchlock  =  TRUE; 

*vx  =  ((float)((xval  *  FT_10K)/767)); 

*vz  =  -((float)((yval  *  FT_10K)/767)); 

*vy  =  gnd_level(*vx,  *vz)  +  200.0; 

editobj(obj[STATS]); 

objreplace(tag[LAUNCH]); 

charstr(xtemp); 

cmov2i(170,220); 

charstr(ytemp); 

closeobjQ; 
}         /*  endofMOUSE3  hit  */ 

/*  As  long  as  LEFT  MOUSE  not  selected,  keep  on  displaying  current  UTM 
grid  coordinates  in  control  panel  area.  */ 

if  (llaunchlock)  { 

editobj(obj[STATS]); 
objreplace(tag[LAUNCH]); 

charstr(xtemp); 
cmov2i(170,220); 
charstr(ytemp); 
closeobj(); 
} 

/*  if  RIGHT  MOUSE  selected  lock  in  target  and  update  control  panel.  */ 

if  (getbutton(MOUSEl)  &&  (!getbutton(MOUSE3))  &&  (!getbutton(MOUSE2)))  { 
ringbell(); 
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xtarget  =  xval; 
ytarget  =  yval; 
targetlock  =  TRUE; 
editobj(obj  [STATS]); 
objreplacej  tag  [TARGET] ) ; 
charstr(xtemp); 
cmov2i(170,140); 
charstr(ytemp); 
closeobj(); 

} 

/*  As  long  as  RIGHT  MOUSE  not  selected  keep  on  displaying  current  UTM 

grid  coordinates  in  control  panel  area.  */ 
if  (Itargetlock)  { 

if  (launchlock)  { 

xdistance  =  ((double) (xval  -  xlaunch)); 

ydistance  =  ((double) (yval  -  ylaunch)); 

distance  =  sqrt((float)(xdistance  *  xdistance  +  ydistance  *  ydistance)); 

distance  =  distance  *  GRID_FACTOR; 

sprintf(dist,"%5.0f  METERS",  distance); 

*direction  =  atan2(ydistance,  xdistance); 

if  (*direction  <  0.0)  *direction  +=  T WOPI; 

*compassdir  =  compass(*direction); 

sprintf(heading,"%d  DEGREES",  (int)*compassdir); 

editobj(obj[STATS]); 

objreplace(tag[TARGET]); 

charstr(xtemp); 

cmov2i(l70,140); 

charstr(ytemp); 

objreplace(tag[HEAD]); 

charstr  (heading); 

cmov2i(ll5,60); 

charstr(dist); 

closeobj(); 

} 
} 

/*  if  launch  position  and  target  location  have  been  selected  by  the 

operator  compute  the  direction  of  the  missile  and  distance  to  target.  */ 

if  (launchlock  &&  targetlock)  { 

xdistance  -  ( (doubiejjxtarget  -  xiaunch)); 
ydistance  =  ((double)(ytarget  -  ylaunch)); 
distance  =  sqrt((9oatj((xdistance  *  xdistance)  — 

(ydistance  *  ydistance))); 
distance  =  distance  *  GRIDFACTOR; 
sprintf(dist,"%5.0f  METERS",  distance); 
*direction  =  atan2(ydistance,  xdistance); 
if  (*direction  <  0.0)  direction  +=  TWOPI; 
*compassdir  =  compass(*direction); 
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} 


sprintf(heading,"%d  DEGREES",  (int)*compassdir); 

editobj(obj[STATS]); 

objreplace(tag[HEAD]); 

charstr(heading) ; 

cmov2i(H5,60); 

charstr(dist); 

closeobjQ; 


/*  add  small  red  and  blue  circles  to  contour  map  to  indicate  launch 
position  and  target  location.  Connect  circles  to  indicate  missile 
Bight  path  */ 

if  (launchlock) 

if  (targetlock)  { 

editobj(obj[FLTPATH]); 

objreplace(tag[MISSILE]); 

circf((float)(xlaunch)/767.0*100.0,  (float) (ylaunch)/767.0*100.0,  0.6); 

move2((float)(xtarget)/767. 0*100.0,  (float)(ytarget)/767. 0*100.0); 

draw2((float)(xlaunch)/767.0*100.0,  (float)(ylaunch)/767.0*100.0); 

objreplace(tag[TGT]); 

circf( (float) (xtarget)/767.0*  100.0,  (float) (ytarget)/767.0*100.0,  0.6); 

closeobjQ; 

} 
else  { 

editobj(obj[FLTPATH]); 

objreplace(tag[MISSILE]); 

circf((float)(xlaunch)/767.0*100.0,  (float)(ylaunch)/767.0*100.0,  0.6); 

move2((float)(xval)/767.0*100.0,  (float)(yval)/767. 0*100.0); 

draw2((float)(xlaunch)/767.0*  100.0,  (float)(ylaunch)/767.0*100.0); 

closeobj(); 

} 

/*  if  MIDDLE  MOUSE  selected,  launch  has  occurred  and  control  transfers 

back  to  main  portion  of  FOG-M  program  displaying  out-the-window  3-D 
view  of  the  flight  area.  */ 

if  (getbutton(MOUSE2)  &&  (!getbutton(MOUSEl))  &&  (!getbutton(MOUSE3)) 
&&  launchlock  &&  targetlock)  { 
ringbellQ; 

while  (getbutton(MOUSE2)); 
break; 

} 
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writemask(SAVEMAP); 
callobj(obj[FLTPATH]); 
writemask  (unmask); 
callobj(obj(  STATS]); 
swapbuffersQ; 

} 
exit: 

cursoff(); 
popmatrix(); 

} 
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RANDNUM 

/*    randnum.c  -  returns  a  random  float  between  zero  and  one  */ 

static  long  seed  =  1234567; 

randseed(newseed) 
long  newseed; 

{ 

seed  =  newseed; 

} 


float  randnumQ 

{ 

long  multQ; 

seed  =  (mult(seed, 31415821)  +  1)  %  100000000; 
return  (seed  /  100000000.0); 


long  mult(p,q) 
long  p,q; 

{ 

long  pO,  pi,  qO,  ql; 

pi  =  p  /  10000; 

pO  =  p  %  10000; 

ql  =  q  /  10000;  . 

qO  =  q  %   10000; 

return((((pO*ql  +  pl*q0)  %  10000)  *  10000  +  p0*q0)  %   100000000); 
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READCONTROLS 


/*  reads  the  values  from  the  operator's  controls  (mouse  and  dials)  */ 

^include  "gl.h"  /*  graphics  lib  defs  */ 

^include  "fogm.h"  /*  fogm  constants  */ 

^include  "device. h"  /*  device  definitions  */ 

read  controls(designate,  greyscale,  flying,  active,  speed,  direction, 
compassdir,  alt,  pan,  tilt,  fovy) 

int  *designate,  *greyscale,  *flying,  *active,  *fovy; 
float  *speed,  *compassdir; 
double  *direction,  *pan,  *  tilt ; 
Coord  *alt; 


{ 


extern  float  randx,  randy,  randz; 
float  randnum(); 
Colorindex  colors[l]; 

/*  quit  if  all  three  mouse  buttons  are  pushed  */ 

if(getbutton(MOUSEl)  &&  getbutton(MOUSE2)  &&  getbutton(MOUSE3))  { 

"flying  =  FALSE; 

*  active  =  FALSE; 

} 
else  { 

if  (getbutton(MOUSE3)  &&  !(getbutton(MOUSE2)))  {     /*  Zoom  In  */ 

*fovy  =  (*fovy  <  (80  +  DELTAFOVY))  ?  80  :  *fovy  -  DELTAFOVY; 

} 

if  (getbutton(MOUSEl)  &&  !(getbutton(MOUSE2)))  {     /*  Zoom  Out  */ 

*fovy  =  (*fovy  >  (550  -  DELTAFOVY))  ?  550  :  *fovy  +  DELTAFOVY; 

} 

if  (getbutton(MOUSE2))    {  /*  designate/reject  target  */ 

if  (*designate)  {    /*  see  if  target  in  sights  */ 
/*pushmatrix(); 

pushviewport(); 

pushattributes(); 

viewport(0,  1023,  0,  767); 

ortho2(0.0,  1023.0,  0.0.    767.0); 

cmov2s((Scoord) (768/2),  (Scoord) (768/2)); 

readpixeis(l, colors); 

if  ((colors[0]  >=  MINTGTCOLOR)  &&  (colors[0]  <=  MAX_TGT_COLOR))  { 
*designate  =  FALSE; 
ringbellQ; 

randx  =  30.0  *  randnum()  -  15.0; 
randy  =  10.0  *  randnum()  -    5.0; 
randz  =  10.0  *  randnum(); 
while  (getbutton(MOUSE2)); 
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/*} 

popattributesQ; 
popviewportQ; 
popmatrix();  */ 

} 

else  {        /*  reject  currently  designated  target  */ 

ringbellQ; 

'designate  =  TRUE; 

/*  re-adjust  tilt  and  pan  values  appropriately  */  ; 

} 
} 

if  (*greyscale  !=  getvaluator(DIAL3))  {  /*  DIAL3  indicates  color  change  */ 

'greyscale  =  !*greyscale; 

setvaluator(DIAL3,*greyscale,0,l); 

colorramp(*greyscale, FALSE); 
} 

*speed  =  (float) (getvaluator(DIAL2)  /  SPEEDSENS);  /*  get  desired  speed  */ 
*alt  =  (Coord)  (getvaluator(DIAL4)); 

*pan  =  DTOR  *  (double)(-getvaluator(MOUSEX))  /  PANSENS; 
*tilt  =  DTOR  *  (double) (getvaluator(MOUSEY))  /  TILTSENS; 

*compassdir  =  (float)getvaluator(DIALO)  /  DIRSENS; 

/*  keep  'direction  between  0  and  360,  update  valuator  if  changed     */ 

if  ('compassdir  >=  360.0)  { 

*compassdir  -=  360.0; 

setvaluator(DIALO,(int)(*compassdir*DIRSENS),  (int)(-360*DIRSENS), 

(int)(720*DIRSENS)); 

} 

if  (*compassdir  <  0.0)  { 

*compassdir  +=  360.0; 

setvaluator(DIALO,(int)(*compassdir*DIRSENS),  (int)(-360*DIRSENS), 
(int)(720*DIRSENS)); 

} 

/'convert  'direction  from  compass  degrees  to  trigonometric  radians      */ 
'direction  =  ('compassdir  <=  90.0)  ?  DTOR  *  (90.0  -  *compassdir)  : 
DTOR  *  (450.0  -  *compassdir); 
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READDATA 


/*  reads  the  raw  16  bit  elevation  and  vegetation  code  data 
from  the  DMA  data  file  and  inserts  it  into  the  global 
gridpixel  array        */ 

^include  "fogm.h" 
#include  "files.h" 


readdataQ 
{ 


int  fd;  /*  file  descriptor  for  the  data  file  *j 

short  row,  col,  rowoffset,  coloffset;     /*  loop  indicies    */ 

extern  short  gridpixel[l00][l00];  /*  DMA  elev  and  veg.  data  */ 


/*  read  the  data  from  the  data  file  into  the  gridpixel  array  */ 

fd  =  open(TERRAIN_FILE,RD); 

lseek(fd,0,0); 

for  (coloffset  =  0;  coloffset  <  NUMXGRIDS  *  10;  coloffset  +=  10)  { 

for  (rowoffset  =  0;  rowoffset  <  NUMZGRIDS*10;  rowoffset  +=  10)  { 
for  (col  =  0;  col  <  10;  ++col)  { 

for  (row  =  0;  row  <  10;  H — -row)  { 

read  (fd,&gridpixel[rowoffset-r  row]  [coloffset  -r-col],  2); 
} 
} 
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ROAD   BOUNDS 


#include  "math.h" 
^include  "fogm.h" 

#define  X  0 
#define  Y  1 
#define  Z      2 

#define  NONE      0 

road   bounds(ptl,  pt2,  pt3,  road  width,  left_ptl,  right_ptl,  left   pt2, 
right   pt2,  first   xgrid,  first_zgrid,    last_xgrid,    last_zgrid) 

float  ptl[3],  pt2[3],  ptS(S],  road_width; 

float  left_ptl[3],  right_ptl[3],  left_pt2[3],  right_pt2[3]; 

int     *first   xgrid,  *last  xgrid,  *first   zgrid,  *last   zgrid; 


{ 


float  delta_x,  delta_z,  seg_dir,  minx,  maxx,  min_z,  max_z; 
float  left_endl(3],  right_endl[3],  left_start2[3],  rightj3tart2[3], 
left_end2[3],  right_end2[3]; 
int  intersection_type; 

/*  determine  the  corner  points  of  the  segment  */ 

delta_x  =  pt2[X]  -  ptl[X]; 

delta_z  =  pt2[Z]  -  ptl[Z|; 

seg_dir  =  atan2(delta_z,  deltax); 

left~endl[X]  =  pt2[X]~+  (cos(seg_dir  +  HALFPI)*road_width/2.0); 

right_endl[X]  =  pt2(X]  +  (cos(seg_dir  -  HALFPI)*road_width/2.0); 

left_endl[Z]  =  pt2[Z]  +  (sin(seg_dir  +  HALFPI)*road_width/2.0); 

right_endl[Z]  =  pt2[Z]  +  (sin(seg_dir  -  HALFPI)*road_width/2.0); 

if((pt2[X]!=pt3|X])||  (Pt2[Z]  !=  Pt3[Z]))  { 

/*  we  are  not  working  with  the  final  segment  of  this  road,  find 

the  intersection  of  this  segment  with  the  next  one  */ 
delta_x  =  pt3[X]  -  pt2(X]; 
delta_z  =  pt3[Z]  -  pt2[Z]; 
seg_dir  =  atan2(delta  z,  delta  x); 

left~start2[X]  =  pt2[Xj+  (cos(7eg_dir  +  HALFPI)*road_width/2.0); 
right_start2[X]  =  pt2(X]  +  (cos(seg_dir  -  HALFPI)*road_width/2.0); 
left_start2[Z]  =  pt2fZ]  +  (sinfsegdir  +  HALFPT)*road_width/2.0); 
nght_start2lZ|  =  pt2lZ]  +  (sinjseg _dir  -  HALFPI)*road   width/2.0); 
left_end2|X|  =  pt3!XI  +  (cos|seg_dir  -  HALFPI)*road_width/2.0); 
right_end2[X]  =  pt3[X]  +  (cos(seg_dir  -  HALFPI)*road_width/2.0); 
left_end2[Z]  =  pt3[Z]  +  (sin(seg_dir  +  HALFPI)*road_width/2.0); 
right_end2[Z]  =  pt3[Z]  +  (sin(seg_dir  -  HALFPI)*road_width/2.0); 

/*  find  the  intersection  point  of  the  left  hand  sides  of  the 

first  and  second  road  segments  */ 
line_intersect2(left_ptl,  leftendl,  left  start2,  left  end2, 
left_pt2,  ^intersection  type); 
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if  (intersection_type  ==  NONE)  { 
left_pt2[X]  =  left_endl[X]; 
left_pt2[Z]  =  left_endl(Z]; 

} 

/*  find  the  intersection  point  of  the  right  hand  sides  of  the 

first  and  second  road  segments  */ 
line_intersect2(right_ptl,  right_endl,  right_start2,  right  end2, 
right   pt2,  &intersection_type); 
if  (intersection_type  ==  NONE)  { 

right_pt2[X]  =  right_endl[X]; 

right_pt2[Z]  =  right_endl[Z]; 


} 
else  { 


} 
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/*  this  is  the  final  segment  of  this  road  */ 
left_pt2[X]  =  left_endl[Xj; 
left_pt2[Z]  =  left_endl[Z|; 
right  j>t2(X]  =  right_endl[X]; 
right_pt2[Zj  =  right_endl[Z]; 


/*  determine  the  min  and  max  x  and  z  values  */ 
min   x  =  left   ptl[Xj; 
max  x  =  left_ptl[X]; 
min   z  =  left_ptl[Z]; 
max_z  =  left_ptl[Z|; 

if  (right_ptl[X]  <  min_x)  min_x  =  right_ptl[X]; 
if  (right_ptl[X]  >  max_x)  max_x  =  right_ptl[X]; 
if  (right   ptl[Z]  <  min_z)  min_z  =  right_ptl[Z]; 
if  (right   ptl[Z]  >  maxz)  max_z  =  right_ptl[Z]; 
if  (left_pt2[X]  <  minx)  minx  =  left_pt2[X]; 
if  (left~pt2[X]  >  maxjc)  max~_x  =  left~_pt2[X|; 
if  (left_pt2[Z]  <  min_z)  minz  =  left_pt2[Zj; 
if  (left_pt2[Z]  >  max_z)  maxz  =  left_pt2[Z]; 
if  (right   pt2[X]  <  min_x)  min_x  =  right   pt2[X]; 
if  (right   pt2[X]  >  max_x)  max_x  =  right_pt2[X]; 
if  (right_pt2[Z]  <  min_z)  min_z  =  right_pt2[Z]; 
if  (right_pt2[Z]  >  max_z)  max_z  =  right_pt2(Z]; 
*first_xg~rid  =  (int)(min_x/FT~100M); 
*first_zgrid  =  (int)(min_z/FT_100M); 
*last_xgrid  =  (int)(max_x/FT_100M); 
"lastzgnd  =  (int  |(max_z/FT_iOOM); 
if  (*first_xgnd  <  0)  *first_xgrid  =  0; 
if  (*first_zgnd  <  0)  *first_zgrid  =  0; 
if  (*last_xgrid  >  98)  *last_xgrid  =  98; 
if  (*last_zgrid  >  98)  *last_zgrid  =  98; 
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SORT  ARRAY 


sort   array(array,  num_entries,  decending,  test_index) 

float  array[l0][3]; 

int  num   entries,  decending,  test_index; 

{ 

int  ij; 

float  temp[3]; 

for  (i  =  0;  i  <  num_entries;  ++i)  { 

for  (j  =  i  +  1;  j  <=  num_entries;  +  +j)  { 

if  (((decending)  &&  ( array [j][ test _index]  >  array [i][test_index]))  || 
((Idecending)  &&  (array [j] [test   index]  <  array[i][test   index])))  { 

temp[0]  =  array  [i][0]; 

tempfl]  =  array  [i][l]; 

temp[2]  =  array[i][2]; 

array  [i][0]  =  arraylj][0]; 

array[i][l]  =  array[j][l]; 

array[i][2]  =  aiTay[Jl[2]; 

array[j][0]  =  temp[0]; 

array  [j][l]  =  temp[l]; 

array[jj[2i  =  temp[2]; 
} 
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UP   LOOK   POS 


/*  compute  the  camera's  lookat  position        */ 

#include  "fogm.h"  /*  fogm  constants  */ 

^include  "math.h"  /*  math  routine  definitions  */ 

#include  "gl.h"  /*  graphics  definitions    */ 

update_look_posit(direction,  pan,  tilt,  vx,  vy,  vz, 
tgtx,  tgty,  tgtz,  designate,  px,  py,  pz) 

double  direction,  pan,  tilt; 

Coord  vx,  vy,  vz,  tgtx,  tgty,  tgtz,  *px,  *py,  *pz; 

int  designate; 

{ 

extern  int  framecnt; 

double  lookdir; 

if  (designate)  {     /*  missile  is  not  locked  on  to  a  target  */ 

/*  compute  direction  camera  is  looking  */ 
lookdir  =  direction  -l-  pan; 

/*  compute  a  coordinate  along  camera's  line  of  sight  */ 
*px  =  vx  +  cos(lookdir)  *  MAXLOOKDIST; 
*pz  -  vz  -  sin(lookdir)  *  MAXLOOKDIST; 

if  (framecnt  <  15)  { 

*py  =  4.0  *  vy  *  (14  -  framecnt)  /  14.0; 
framecnt+  +  ; 

} 
else    { 

*py  =  vy  +  MAXLOOKDIST  *  tan(tilt); 

} 
} 

else  { 

*px  =  tgtx; 
*py  =  tgty; 
*pz  =  tgtz; 

} 
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UP   MSL   POSIT 


/*  Compute  new  missile  position  */ 

^include  "gl.h"  /*  graphics  definitions  */ 

^include  "device. h"  /*  graphics  device  definitions  */ 

^include  "fogm.h"  /*  fogm  constants  */ 

^include  "math.h"  /*  math  function  declarations  */ 

^include  <sys/types.h>      /*  contains  the  time  sturcture  tms  */ 

^include  <sys/times.h>      /*  for  time  calls  */ 

update  missile  posit  (direction,  compassdir,  speed,  designate, 
tgtx,  tgty,  tgtz,  vx,  vy,  vz,  flying) 

double  *direction; 

float  *compassdir; 

float  speed; 

int  designate; 

Coord  tgtx,  tgty,  tgtz; 

int  *flying; 

Coord  *vx,  *vy,  *vz; 


{ 


static  long  seconds; 

static  long  lastsec  =  -999;        /*  -999  is  flag  to  indicate  no  value  */ 

struct  tms  timestruct; 

float  deltadist,  gndlevel,  gnd_level(),  compassQ,  ht_above_tank; 

long  float  deltax,  deltaz,  dist   to  tank; 

seconds  =  times(&timestruct); 

/*  compute  distance  missile  must  move  ahead  to  maintain  speed  */ 
if  (lastsec    ==  -999) 

deltadist  =  0.0; 
else 

deltadist  =  (speed/FPS_TO_KTS)  *  (seconds  -  lastsec); 

lastsec  =  seconds;  /*  save  for  next  pass  */ 

if  (designate)  {     /*  missile  under  operator  contol,  not  locked  on  tgt  */ 

*vx  +=  deltadist  *  cos(*direction); 

*vz  -=  deltadist  *  sin(*direction); 

/*  keep  missile  at  least  50  ft  above  ground  level 

gndlevel  =  gnd_level(*vx,  *vz); 

if  (*vy  <  (gndlevel  +  50.0))  *vy  =  gndlevel  +  50.0; 

} 

else    { 

deltax  =  *vx  -  tgtx; 

deltaz  =  *vz  -  tgtz; 

dist_to_tank  =  hypot(deltax,  deltaz); 
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if  (deltadist  >  (float)dist_to_tank)  {      /*  hit  on  target  */ 
deltadist  =  (float)dist_to_tank  -  5.0; 
"flying  =  FALSE; 
lastsec  =  -999;  /*  no  value  flag  for  next  launch  */ 

} 

"direction  =  (double)atan2((float)deltaz,  (float)-deltax); 
if  ("direction  <  0.0)  "direction  +=  TWOPI; 
"compassdir  =  compass(  "direction); 

setvaluator(DIALO,(int)(*compassdir*DIRSENS),  (int)(-360*DIRSENS), 
(int)(720*DIRSENS)); 


*vx  +=  (deltadist  *  cos( "direction)); 

*vz  -=  (deltadist  *  sin(*direction)); 

htabovetank  =  (float) *vy  -  gnd_level(tgtx,tgtz); 

*vy   -=  (Coord)  ((htabovetank  *  deltadist)  /  (float)dist_to_tank) 
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VIEW   BOUNDS 


^include  "fogm.h" 
#include  "gl.h" 
^include  "math.h" 

view_bounds(vx,  vy,  vz,  px,  py,  pz,  tilt,  fovy, 

firstxgrid,  firstzgrid,  lastxgrid,  lastzgrid) 

Coord  vx,vy,vz; 

double  tilt; 

int  fovy; 

short  *firstxgrid,  *firstzgrid,  *lastxgrid,  *lastzgrid; 

{ 

float  ix,  iz;        /*  the  intersection  points  */ 

float  lookdir; 

float  deltax,  deltay,  deltaz,  delta_alt,  fx,  fy,  fz; 

float  half_fovy; 

float  lower_edge_angle; 

/*  compute  the  direction  the  camera  is  looking  */ 
lookdir  =  atan2((float)(vz  -  pz),  (float)(-(vx-px))); 
if  (lookdir  <  0.0)  lookdir  +=  TWOPI; 

if  (vy  >  py)  { 

/*  tilt  angle  is  negative  */ 

deltax  =  px  -  vx; 

deltay  =  py  -  vy; 

deltaz  =  pz  -  vz; 

delta_alt  =  pow((float)MIN,  ALTSCALE)  -  vy; 

} 
else  { 

/*  tilt  angle  is  positive,  use  the  lower  fustrum  edge  instead 
of  the  line  of  sight  to  compute  the  view  bounds  */ 

/*  compute  a  coordinate  along  the  lower  fustrum  edge  */ 

halfjovy  =  ((float)fovy/20.0*DTOR); 

lower_edge_angle  =  tilt  -  half  fovy; 

fx  =  v~x  +  cos(lookdir)*MAXLOOKDIST; 

fz  =  vz  -  sin(lookdir)*MAXLOOKDIST; 

fy  =  Vy  +  tan(lower_edge_angle)*MAXLOOKDIST; 

deltax  =  fx  -  vx; 

deltay  =  fy  -  vy; 

deltaz  =  fz  -  vz; 

delta_alt  -  pow((float)MIN,  ALTSCALE)  -  vy; 
} 

ix  =  vx  +  ((deltax/deltay)*delta  alt); 
iz  =  vz  +  ((deltaz/deltay)*delta_alt); 


/*  compute  which  grid  objects  should  be  sent  through  the  geometry 
pipeline  */ 
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if  (deltay  >  0.0)  { 

/*  the  fustrum  is  looking  totally  skyward,  don't  bother  doing 

any  terrain  */ 
*firstxgrid  =  0; 
*firstzgrid  =  0; 
*lastxgrid  =  0; 
*lastzgrid  =  0; 


} 
else  { 


/*  display  20  grid  squares  on  all  sides  of  the  intersection  point  */ 
*firstxgrid  =  (int)(ix/FT_100M)  -  20; 
*lastxgrid  =  (int)(ix/FT_100M)  +  20; 
*firstzgrid  =  (int)(-iz/FT_100M)  -  20; 
♦lastzgrid  =  (int)(-iz/FT_100M)  +  20; 

/*  insure  that  objects  drawn  include  the  current  missile  position  */ 
if  ((int)(vx/FT_100M)  <  *firstxgrid) 

*firstxgrid  =  (int)(vx/FT_100M); 
if  ((int)(vx/FT_100M)  >  *lastxgrid) 

*lastxgrid  =  (int)(vx/FT_100M); 
if  ((int)(-vz/FT_100M)  <  *firstzgrid) 

*firstzgrid  =  (int)(-vz/FT_100M); 
if  ((int)(-vz/FT_100M)  >  *lastzgrid) 

*lastzgrid  -  (int)(-vz/FT_100M); 
if  (*firstzgrid  <  0)  *firstzgrid  =  0; 
if  (*firstxgrid  <  0)  *firstxgrid  =  0; 
if  (*lastzgrid  >  98)  *lastzgrid  =  98; 
if  (*lastxgrid  >  98)  *lastxgrid  =  98; 
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